JP2001249828A - 情報処理装置、不具合解析プログラムを格納したコンピュータ読み取り可能な記憶媒体、不具合解析方法、及びアプリケーションプログラム開発支援システム - Google Patents

Abstract

(57)【要約】 【課題】 対話形式でユーザーから指摘された不具合箇
所とプログラムの実行履歴情報から不具合要因と解決策
を特定し、これをユーザーに提示し、また、特定した不
具合要因と解決策から、該不具合を解決したプログラム
を生成してユーザーに提示する。 【解決手段】 プログラムの実行履歴情報をもとに、該
プログラムの動作状況を時系列にユーザーに表示する表
示手段と、表示された動作状況の中でユーザーが不具合
の箇所を指定するための入力手段と、前記入力手段によ
ってユーザーから指定された不具合の箇所と該プログラ
ムの動作状況から該不具合要因を解析し、この不具合要
因を解決するための解決策を特定する動作解析手段と、
を有し、前記動作解析手段は、特定した解決策を反映さ
せた前記動作状況を再作成し、前記表示手段は、前記不
具合要因と前記解決策と再作成した動作状況とをユーザ
ーに表示する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、リアルタイムＯＳ
（Real-Time Operating System）等で動作するマルチタ
スク・プログラムのテストやデバッグなどに利用される
情報処理装置、不具合解析プログラムを格納したコンピ
ュータ読み取り可能な記憶媒体、不具合解析方法、及び
アプリケーションプログラム開発支援システムに関す
る。

【０００２】

【従来の技術】ＴＲＯＮ（The Real-time Operating sy
stem Nucleus）に代表されるリアルタイムＯＳの適用範
囲は、マイクロプロセッサ技術の発展により拡大の一途
をたどっており、産業用途のみならず、通信機器やオフ
ィス機器などの業務機器分野、家電や携帯電話などの民
生用機器などへも急激に拡大している。

【０００３】一般に、このようなリアルタイムＯＳ配下
で実行されるマルチタスク方式のアプリケーション・プ
ログラムの不具合解析をするために、各プログラムの動
きを追跡するのは容易でない。リアルタイムＯＳでは、
特定のタイミングで動作するタスクを次々と切り替えて
いくことによって、複数のプログラムを動かすマルチタ
スク方式が採られているため、一つのプログラムを追う
だけでは解析できないからである。

【０００４】そのため、プログラムの動作を追跡する機
能を有するＯＳが開発され、プログラムの動作状況を解
析するためのひとつの手掛りとして、プログラムの実行
履歴情報が用いられている。図４２に示すように、プロ
グラムの実行履歴情報４は、プログラム動作の追跡機能
を有するＯＳ１０１によってＯＳ１０１のメモリ上に出
力されたり、更にデバッガ１０２等の開発ツールによっ
てデバッガ１０２等が持つメモリ上に出力されたりす
る。

【０００５】図４４に、μＩＴＲＯＮ（Micro Industri
al TRON ）仕様のプログラム実行履歴情報を例示する。
図４４（ａ）は、システムコール発行履歴のフォーマッ
ト例であり、１レコードで１事象を表し、機能のタイプ
（type）、発行元タスク（oid）、システムコールの種
類（sysid）、発行先タスク（obj）で構成されている。
出力される実行履歴情報の種類としては、このようなシ
ステムコール発行履歴の他に、タスク切り換え履歴、ハ
ンドラ実行履歴などがある。

【０００６】図４４（ｂ）は、ＯＳ１０１やデバッガ１
０２等によってメモリ上に出力された実行履歴データの
例である。（ｉ）は、タスク切り換えが行われたことを
表しており、アイドル状態（タスク＝０）からタスク１
（タスク＝１）に制御が移行している。（ii）は、シス
テムコールが発行されたことを表しており、タスク１
（oid=1）からsta_tsk（sysid=-19）という種類のシス
テムコールがタスク２（obj=2）に対して発行されてい
る。

【０００７】

【発明が解決しようとする課題】上述したように、プロ
グラムの実行履歴をデータとして保存することができる
ようになり、プログラムの不具合を解析するための手掛
りとして利用されているが、以下のような問題がある。

【０００８】第１に、コントローラのメモリ容量の関係
から、履歴情報を採取できる量には制限があり、実際に
は図４３のように、履歴情報を細切れに保存することに
なってしまう。特に、ローコストを目指したシステムの
場合、このメモリ容量はかなり限定されてしまう。

【０００９】第２に、出力される履歴情報は、図４４に
示したように、主に数字からなる文字の羅列であり、し
かも大量に出力されがちであることから、この履歴情報
を手掛りにプログラムの動作軌跡を辿って不具合を解析
することは、大変困難である。

【００１０】その結果、プログラムの不具合解析には、
依然として多大な時間を要し、開発コストや開発期間な
どに大きな影響を与えていた。

【００１１】また、従来、ある実行環境向けに行うプロ
グラミング段階において、その実行環境管理下にある資
源の状態変化を把握することや、プログラミング内容の
整合性判定、そして実行環境ハードウェアが持つ割り込
み機能等を考慮しながらプログラミングすることはでき
ても、その整合性を確認する術がなく、実際にそのプロ
グラムから作成される実行オブジェクトを、実行環境と
同じ条件で実行させ、アプリケーションシステムの振る
舞いを確認する方法が取られている。

【００１２】しかしながら、上述した従来の方法では、
単純なプログラミングミスも実行オブジェクトを実際に
実行させないと、そのミスが判明しないという問題があ
った。

【００１３】そこで、本発明はこのような課題を解決す
るためになされたものであって、対話形式でユーザーか
ら指摘された不具合箇所とプログラムの実行履歴情報か
ら、不具合要因と解決策を特定し、これをユーザーに提
示することができる情報処理装置、及び情報処理装置に
搭載される不具合解析プログラムを格納したコンピュー
タ読み取り可能な記憶媒体を提供することを目的とす
る。

【００１４】本発明の第２の目的は、前記特定した不具
合要因と解決策から、該不具合を解決したプログラムを
生成してユーザーに提示することができる情報処理装
置、及び情報処理装置に搭載される不具合解析プログラ
ムを格納したコンピュータ読み取り可能な記憶媒体を提
供することを目的とする。

【００１５】更に、本発明の第３の目的は、プログラミ
ング段階において、その実行環境の動作規則に従いアプ
リケーションシステムの振る舞いを視覚的に確認し、早
期にプログラミングの不整合発見を行い、作業行程の戻
りを低減させることにより、効率的なアプリケーション
システム開発を可能とすることのできるアプリケーショ
ン開発システムを提供することを目的とする。

【００１６】

【課題を解決するための手段】上記課題を解決するため
に、本発明は、プログラムの実行履歴情報をもとに、該
プログラムの動作状況を時系列にユーザーに表示する表
示手段と、表示された動作状況の中でユーザーが不具合
の箇所を指定するための入力手段と、前記入力手段によ
ってユーザーから指定された不具合の箇所と該プログラ
ムの動作状況から該不具合要因を解析し、この不具合要
因を解決するための解決策を特定する動作解析手段とを
有し、前記動作解析手段は、解決策を反映させた前記動
作状況を再作成し、前記表示手段は、前記不具合要因と
前記解決策と再作成した動作状況とをユーザーに表示す
ることを特徴とする。

【００１７】このとき、前記解決策を反映させる箇所を
特定することができない場合には、更に、ユーザーによ
って該解決策を反映させる箇所を指定させ、前記動作解
析手段は、この指定された箇所に該解決策を反映させた
前記動作状況を再作成し、前記表示手段は、前記不具合
要因と解決策と再作成した動作状況とをユーザーに表示
することを特徴とする。

【００１８】更にまた、前記解決策と前記実行履歴情報
とをもとに、本来の仕様を満たすプログラムのスケルト
ンを自動生成することを特徴とする。

【００１９】本発明により、対話形式により、ユーザー
から指摘された不具合箇所とプログラムの実行履歴情報
から不具合要因と解決策を特定し、これをユーザーに提
示することができる。

【００２０】また、前記特定した不具合要因と解決策か
ら、該不具合を解決したプログラムを生成して同様にユ
ーザーに提示することができる。

【００２１】更にまた、本発明は、ハードウェア資源上
で実行されるアプリケーションプログラムの開発に用い
られる開発支援システムにおいて、前記ハードウェア資
源、およびソフトウェア部品を含む実行環境での実行時
におけるシステム環境と、該実行環境の動作規則を定義
する環境定義部と、環境定義に基づいて前記実行環境に
おけるアプリケーションプログラムの仮想的な実行状態
（以下「仮想実行状態」という。）を検証するチェック
部と、前記仮想実行状態を可視的に表示するための表示
情報を作成する表示情報作成部とを有することを特徴と
する。

【００２２】本発明においては、前記表示情報を表示さ
せる表示装置と、前記表示装置の表示画面上に形成さ
れ、可視的に表示された前記仮想実行状態を変化させる
操作を該表示画面上で操作するインターフェース部とを
設けることが好ましい。

【００２３】このような本発明によれば、実行環境の動
作規則等の環境定義に従い、実際のハードウェア資源上
における実行状態を再現することができ、これによりア
プリケーションシステムの振る舞いを検証することがで
きるため、従来方法よりも早期のプログラミングの不整
合発見が行うことができ、作業行程の戻りも少なくなり
効率的なアプリケーション開発が可能となる。

【００２４】本発明のその他の目的、特徴、効果は、以
下で図面を参照して述べる詳細な説明により、一層明ら
かになるものである。

【００２５】

【発明の実施の形態】以下、図面に基づいて、本発明の
実施形態について説明する。

【００２６】図１は本発明に係る情報処理装置の一実施
形態を示す概略構成図であり、図２は本発明に係る情報
処理装置に搭載される不具合解析プログラムを格納した
コンピュータ読み取り可能な記憶媒体の処理の流れを示
した流れ図である。

【００２７】図１において、この情報処理装置は、ユー
ザー５からの入力１１を受付け、又ユーザー５に情報を
提示１２するユーザーインタフェース部１と、ユーザー
インタフェース部１が受付けたユーザー５からの入力情
報を解析してタスク動作判定部３に送る要求解析部２
と、実行履歴ファイル４に格納されているプログラムの
実行履歴情報１１とシステムコール対応テーブル７とタ
スク動作判定部３からの情報をもとにプログラムの不具
合要因とその解決策を特定し、各種解析結果情報をユー
ザーインタフェース部１に送り、さらに解析結果情報か
ら不具合を解決するプログラムを生成してプログラムフ
ァイルに出力するタスク動作判定部３とから構成され
る。

【００２８】続いて、図２をもとに、全体の処理の流れ
を説明する。

【００２９】ユーザーインタフェース部１は、予めタス
ク動作判定部３がプログラムの動作履歴情報１１をもと
に作成した検証データ１４（図３）をユーザー５に表示
する（ST01）。ユーザー５は表示された検証データ１４
を見て、動作的に不具合がないと確認した場合、処理を
終了する（ST04）。一方、ユーザー５は表示された検証
データ１４の中に不具合を発見した場合、その不具合箇
所を指摘する（ST05）。ユーザーインタフェース部１
は、ユーザー５が入力した不具合の箇所１２を、要求解
析部２に転送する（ST06）。

【００３０】次に、要求解析部２は、ユーザーインタフ
ェース部１から受取ったユーザー５が入力した指摘箇所
１２と先にタスク動作判定部３が作成した検証データ１
４から、比較データ１３（図４）を作成し（ST07）、作
成した比較データ１３をタスク動作判定部３に転送する
（ST08）。

【００３１】次に、タスク動作判定部３は、要求解析部
２から受取った比較データ１３と先に作成しておいた検
証データ１４とを比較して、要求タスクの状態を検索し
（ST09）、不具合の要因を解析する（ST10）。タスク動
作判定部３は不具合の要因を特定したら、不具合を解決
する機能を検証データ１４に反映させた上で、検証デー
タ１４をユーザーインタフェース部１に転送する（ST1
1）。続いて、タスク動作判定部３は、判定結果データ
１（図５）及び判定結果データ２（図６）を作成してユ
ーザーインタフェース部１に転送する（ST12）。

【００３２】ここまでで不具合が全て解決されていて
（ST13）、且つ処理終了をする場合（ST15）には、ST11
で更新した検証データ１４をもとに不具合を解決した正
常プログラム・ソース１８を生成し（ST16）、ユーザー
インタフェース部１に制御を戻す。一方、未解決の不具
合要因が残っている場合（ST14）、不具合を解決するた
めにユーザーに問い合せる不具合解決用質問データ１７
（図７）を作成し、ユーザーインタフェース部１に転送
し（ST14）、ユーザーインタフェース部１に制御を戻
す。

【００３３】以上説明したST01からST16までの処理を、
プログラムの不具合が解決されて処理を終了するまで繰
り返す。

【００３４】次に、実際に不具合が存在するプログラム
例に基づいて、本発明の不具合解析プログラムを格納し
たコンピュータ読み取り可能な記憶媒体を搭載した情報
処理装置の処理動作について、更に詳細に説明する。

【００３５】ここでは、μＩＴＲＯＮ３．０仕様のリア
ルタイムＯＳ配下で動作するアプリケーション・プログ
ラムを例に説明する。

【００３６】（第１実施例）本実施例では、アラーム機
能付きの時計のプログラムを想定する。本プログラムで
使用するタスクは以下の３本である。

【００３７】 （１）startup （task_ID=1,priorty=1）［アラーム設
定モード］ （２）タスクＡ（task_ID=2,priorty=3）［ノーマルモ
ード］ （３）タスクＢ（task_ID=3,priorty=2） 本プログラムは、アラームを設定すると（アラーム設定
モードを処理すると）、ノーマルモードに移行し、その
後処理を終了するものであり、本来は図８に示すタイム
チャートのような動作を想定して作成されたアプリケー
ション・プログラムである。従って、例えば処理終了時
点を注目してみると、タスクＡ（ノーマルモード）で処
理が終了する、つまりその時点での最終実行タスクはタ
スクＡである、というのがこのプログラムの本来の仕様
である。

【００３８】ところが、実際にこのプログラムを動作さ
せてみたところ、図９に示すような結果が得られたとす
る。実行結果の処理終了時点を注目してみると、startu
p タスク（アラーム設定モード）で処理が終了してい
る。すなわち、このプログラムは本来の仕様を満たして
いない、このプログラムには不具合が潜在しているとい
うことである。

【００３９】このような状況において、ユーザー５は本
発明の情報処理装置及び情報処理装置に搭載された不具
合解析プログラムを格納したコンピュータ読み取り可能
な記憶媒体を使用して、以下のように不具合を解決する
ことができる。

【００４０】［処理１］ユーザーインタフェース部１の
処理の流れを図１０示す。

【００４１】ユーザーインタフェース部１は、予めタス
ク動作判定部３がプログラムの動作履歴情報１１をもと
に作成した検証データ１４（図３）をユーザー５に表示
する（ST21〜ST24）。ユーザー５への表示例を図１１に
示す。図１１のようにプログラムの各タスクの動作とタ
スクの切り換えの様子を時系列に表せば、ユーザー５は
表示されたプログラムの動作における不具合を指摘しや
すい。特に、数字の羅列である実行履歴情報１１をグラ
ッフィックで表現することは有効である。

【００４２】ここで、ユーザー５は当該プログラムの不
具合箇所を指摘する入力を行う（ST26）。この場合、図
１１に示した位置（最終イベントの後のタスクＡの位
置）にマウスカーソルを指定したとする。この指定位置
が、ユーザー５が指摘した不具合の箇所となる。本来の
プログラムの仕様では、この時点ではタスクＡは実行状
態でなければならないはずである。

【００４３】ユーザーインタフェース部１は、ユーザー
５が入力した不具合の箇所データ１２を、要求解析部２
に転送（ST27）し、要求解析部２に制御を移す。このと
き転送する不具合箇所データ１２は、図１１においてマ
ウスカーソルを指定した位置、すなわちイベント順を示
していたＸ軸とタスクを示していたＹ軸との座標位置で
一意に認識することができる。ユーザーが指摘した箇所
データ１２は、Ｘ＝７，Ｙ＝３である。

【００４４】続いて、図１２に要求解析部２の処理の流
れを示す。

【００４５】要求解析部２は、ユーザーインタフェース
部１から受取った不具合箇所データ１２と先にタスク動
作判定部３が作成した検証データ１４から、要求内容を
解析する。まず、Ｘ座標値と検証データ１４のイベント
とを比較し、ユーザー５の要求タイミングを特定する
（ST28）。次に、Ｙ座標値と検証データ１４のアイテム
順から、ユーザーが要求しているタスクを特定する（ST
29）。このときの処理イメージを図１３に示す。すなわ
ち、ユーザー５の要求タイミングはイベントの最後（第
７イベントの位置）、要求タスクはタスクＡ（３番目の
アイテム）である。

【００４６】要求解析部２は、このようにして比較デー
タ１３を作成し（ST30）、作成した比較データ１３をタ
スク動作判定部３に転送して、制御をタスク動作判定部
３に移す。尚、このときの検証データ１４と比較データ
１３を図１６に示す。

【００４７】［第１次要求］この場合の要求タスクはタ
スクＡであり、要求タイミングはイベントの最後であ
る。

【００４８】［処理２］続いて、図１４にタスク動作判
定部３の処理の流れを示す。

【００４９】タスク動作判定部３は、要求解析部２から
受取った比較データ１３と先に作成しておいた検証デー
タ１４とを比較して、要求タスクの状態を検索する（ST
31）。図１６に示す検証データ１４を検索してみると、
イベントの最後の時点でのタスクＡの状態は、「実行可
能 （READY）」状態であることが判る（ST32）。「実行
可能」状態にあるタスクとは、実行する準備は整ってい
るが、自分より優先度の高いタスクもしくは優先度が自
分と同じであるタスクが「実行 （RUNNING）」状態であ
るために、実行できない状態にある、言いかえると、実
行できる状態のタスクの中で自分が最高の優先順位にな
ればいつでも実行できる状態にあるタスクである。

【００５０】本発明の情報処理装置の不具合解析処理が
終了するのは（目的を達成するのは）、ユーザーが第１
次要求で指摘したタスク、すなわちタスクＡがイベント
の最後の時点で「実行」状態になることである。

【００５１】タスクＡを「実行」状態にするまで（不具
合要因を特定するまで）、以下に説明する判定結果デー
タ１、判定結果データ２を作成し、作成した判定結果デ
ータから本来あるべき処理を特定し、それを検証データ
１４に反映させる。このときの各データの状態を図１７
に示す（但し、図１７は処理完了状態の図である）。

【００５２】まず、Ｎの値を判定結果データ１の（１）
欄と判定結果データ２の（１）欄に入れる（ST33）。こ
こでは第１次要求であるため、Ｎの値は「１」である。
判定結果データ１の（１）欄と判定結果データ２の
（１）欄のそれぞれの欄に「１」が入る。

【００５３】次に、判定結果データ１の（２）欄に要求
タスクであるタスクＡを入れ、判定結果データ１の
（３）欄にタスクＡの状態を入れる（ST34）。

【００５４】次に、検証データ１４から、イベントの最
後の時点で「実行」であったタスクを検索する（ST3
5）。この場合、イベントの最後の時点で「実行」であ
ったタスクは、startupタスクである。検索したこのタ
スクを判定結果データ２に入れる（ST36）。

【００５５】次に、判定結果データ２に入れたタスク
（この場合、startup タスク）が「ext_tsk」 を発行し
た場合の検証データ１４を作成する（ST37）。具体的に
は、７番目のイベントに、startup タスクが「ext_ts
k」を発行するというイベントを検証データ１４に作成
するのである。（必然的に、第８イベントとしてタスク
切り換え（「Task Dispatch」）が発生する。）そし
て、このイベント（第７〜８イベント）を検証データ１
４に反映させたことで、第１次要求のタスクＡが「実
行」状態に遷移したかどうかを、検証データ１４から検
索するのである（ST38)。

【００５６】以上のST33〜ST39までの処理を、第１次要
求のタスクＡが「実行」状態になるまで繰り返す（ST3
9）。

【００５７】この場合に、「実行」状態に遷移したの
は、タスクＡではなく、タスクＢである。従って、再び
ST33に戻って、タスクＡがイベントの最後の時点で「実
行」状態になるための処理を行う。

【００５８】［処理３］まず、Ｎの値を判定結果データ
１の（１）欄と判定結果データ２の（１）欄に入れる
（ST33）。ここでは第１次要求であるため、Ｎの値は
「１」である。それぞれの欄に「１」が入る。

【００５９】次に、判定結果データ１の（２）欄に要求
タスクであるタスクＡを入れ、判定結果データ１の
（３）欄にタスクＡの状態を入れる（ST34）。検証デー
タ１４から、タスクＡの状態は「実行可能」であること
が判る。

【００６０】次に、検証データ１４から、イベントの最
後の時点で「実行」状態であったタスクを検索する（ST
35）。この場合、イベントの最後の時点で「実行」状態
であったタスクはタスクＢである。検索したこのタスク
Ｂを判定結果データ２に入れる（ST36）。

【００６１】次に、判定結果データ２に入れたタスク
（この場合、タスクＢ）が「ext_tsk」を発行した場合
の検証データ１４を作成する（ST37）。具体的には、９
番目のイベントに、タスクＢが「ext_tsk」を発行する
というイベントを検証データ１４に作成するのである。
（必然的に、第１０イベントとしてタスク切り換え
（「Task Dispatch」）が発生する。）そして、このイ
ベント（第９〜１０イベント）を検証データ１４に反映
させたことで、第１次要求のタスクＡが「実行」状態に
遷移したかどうかを、検証データ１４から検索するので
ある（ST38）。

【００６２】この場合は、タスクＡが「実行」の状態に
遷移したので、処理終了のフラグ等をセットして（ST5
1）、イベント７〜１０を反映させた検証データ１４か
ら今回の不具合を解決したプログラムのスケルトンを生
成し、プログラムファイル６に出力する（ST52）。この
ときのプログラムの生成例を図１８に示す。図１８の
（ａ）及び（ｂ）に示すステップが、今回の不具合要因
とその解決策であった。

【００６３】図１７に示すように、第１次要求のタスク
Ａが「実行」状態に至るまで要した判定結果データ１，
判定結果データ２と検証データ１４を、ユーザーインタ
フェース部１に転送し、制御をユーザーインタフェース
部１に戻す。

【００６４】ユーザーインタフェース部１は、タスク動
作判定部３から転送された検証データ１４、判定結果デ
ータ１，判定結果データ２をユーザーに表示する。これ
により、今回の不具合の要因とその解決策をユーザー５
に提示することができ、また、本来の仕様に沿ったプロ
グラムの動作をユーザー５に提示することができる。

【００６５】また、本来の仕様を満たしたプログラムが
プログラムファイル６に出力されているので、ユーザー
５はこれを利用することができる。

【００６６】（第２実施例）本実施例で想定するプログ
ラムが使用するタスクは以下の４本である。

【００６７】 （１）startup （task_ID=1,priorty=1） （２）タスクＡ（task_ID=2,priorty=2） （３）タスクＢ（task_ID=3,priorty=2） （４）タスクＣ（task_ID=4,priorty=2） （使用するセマフォ：Semaphore（ID=1,初期セマフォカ
ウンタ=0））本プログラムは、第１実施例と同様に、本
来は図１９に示すタイムチャートのような動作を想定し
て作成されたアプリケーション・プログラムである。従
って、例えば処理終了時点を注目してみると、タスクＢ
で処理が終了する、つまりその時点での最終実行タスク
はタスクＢである、というのがこのプログラムの本来の
仕様である。

【００６８】ところが、実際にこのプログラムを動作さ
せてみたところ、図２０に示すような結果が得られたと
する。実行結果によると、「Idle Mode」（レディーキ
ューにタスクがない状態）になっている。

【００６９】このような状況において、ユーザー５は本
発明の情報処理装置及び情報処理装置に搭載された不具
合解析プログラムを格納したコンピュータ読み取り可能
な記憶媒体を使用して、以下のように不具合を解決する
ことができる。

【００７０】［処理１］図１０のフローチャートに沿っ
て、処理の流れを説明する。

【００７１】ユーザーインタフェース部１は、予めタス
ク動作判定部３がプログラムの動作履歴情報１１をもと
に作成した検証データ１４をユーザー５に表示する（ST
21〜ST24）。

【００７２】ここで、ユーザー５は不具合箇所を指摘す
る入力を行う（ST26）。この場合、実施例１と同様に、
ユーザー５はイベントの最後を指摘したものとする。こ
の指定位置が、ユーザー５が指摘した不具合の箇所とな
る。本来のプログラムの仕様では、この時点ではタスク
Ｂは実行状態でなければならないはずである。

【００７３】ユーザーインタフェース部１は、ユーザー
５が入力した不具合の箇所データ１２を、要求解析部２
に転送（ST27）し、要求解析部２に制御を移す。ユーザ
ーが指摘した箇所データ１２は、Ｘ＝１２，Ｙ＝４であ
る。

【００７４】要求解析部２の処理の流れを図１２のフロ
ーチャートに沿って説明する。

【００７５】要求解析部２は、ユーザーインタフェース
部１から受取った不具合箇所データ１２と先にタスク動
作判定部３が作成した検証データ１４から、要求内容を
解析する。まず、Ｘ座標値と検証データ１４のイベント
とを比較し、ユーザー５の要求タイミングを特定する
（ST28）。次に、Ｙ座標値と検証データ１４のアイテム
順から、ユーザーが要求しているタスクを特定する（ST
29）。この場合、ユーザー５の要求タイミングはイベン
トの最後（第１２イベントの位置）、要求タスクはタス
クＢ（４番目のアイテム）である。

【００７６】要求解析部２は、このようにして比較デー
タ１３を作成し（ST30）、作成した比較データ１３をタ
スク動作判定部３に転送して、制御をタスク動作判定部
３に移す。尚、このときの検証データ１４と比較データ
１３を図２１に示す。

【００７７】［第１次要求］この場合のユーザー５の要
求タスクはタスクＢであり、要求タイミングはイベント
の最後である。

【００７８】［処理２］続いて、タスク動作判定部３の
処理の流れを図１４のフローチャートに沿って説明す
る。

【００７９】タスク動作判定部３は、要求解析部２から
受取った比較データ１３と先に作成しておいた検証デー
タ１４とを比較して、要求タスクの状態を検索する（ST
31）。図２１に示す検証データ１４を検索してみると、
要求タイミングである「イベントの最後」の時点でのタ
スクＢの状態は、「待ち （WAITING）」状態であること
が判る（ST32、ST40）。「待ち」状態にあるタスクと
は、そのタスクを実行できる何らかの条件が整わないた
めに実行できない状態にある、言いかえると、何らかの
条件が満たされるのを待っている状態にあるタスクであ
る。

【００８０】本発明の情報処理装置の不具合解析処理が
終了するのは（目的を達成するのは）、ユーザーが第１
次要求で指摘したタスク、すなわちタスクＢがイベント
の最後の時点で「実行」状態になることである。

【００８１】この場合には、タスクＢの状態を「実行」
状態にする前に、まず「実行可能」状態にする必要があ
る。「待ち」状態にあるタスクは、直接「実行」状態に
は移行できないためである。その処理を以下に説明す
る。

【００８２】まず、Ｎの値を判定結果データ１の（１）
欄と不具合解決用質問データの（１）欄に入れる（ST4
5）。ここでは第１次要求であるため、Ｎの値は「１」
である。それぞれの欄に「１」が入る。

【００８３】次に、判定結果データ１の（２）欄に要求
タスクであるタスクＢを入れ、判定結果データ１の
（３）欄にタスクＢの状態（「待ち」）を入れる（ST4
6）。

【００８４】次に、この第１次要求の要求タスクＢを
「実行可能」状態に遷移させることができるシステムコ
ールをシステムコール対応テーブル７から検索する（ST
47）。このシステムコール対応テーブル７には、解決策
を特定するためのプログラム機能対応情報が格納されて
おり、その一例を図１５に示す。

【００８５】この場合、図２１の検証データ１４による
と、タスクＢは「slp_tsk」によって「（起床）待ち」
の状態にあるため、図１５のシステムコール対応テーブ
ル７から「slp_tsk」に対応するシステムコールを検索
するのである。図１５のシステムコール対応テーブル７
を検索すると、２番目のエントリに「slp_tsk」があ
り、それに対応するシステムコールは「wup_tsk」であ
る。この「wup_tsk」を発行すれば、タスクＢの状態を
「待ち」から「実行可能」に遷移させることができるの
である。検索結果の「wup_tsk」を不具合解決用質問デ
ータの（３）欄に入れる（ST48）。

【００８６】次に、不具合解決用質問データの（２）欄
に、タスクＢの状態を「待ち」から「実行可能」に遷移
させるシステムコールである「wup_tsk」の発行対象タ
スクを入れる（ST49）。この場合、発行対象タスクはタ
スクＡである。

【００８７】この「wup_tsk 」を「何時」「何処」で発
行するか、ということは機械的には決められない。発行
するタイミング、発行する場所によって、処理が変わっ
てしまうからである。従って、このシステムコール「wu
p_tsk」を「何時」「何処」で発行するべきなのかをユ
ーザー５に問合せる。この問合せのためのデータが不具
合解決用質問データなのである。

【００８８】この不具合解決用質問データによる問合せ
を第２次要求とする（Ｎに１加算する（ST50））。ユー
ザーインタフェース部１に制御を戻し、ユーザー５に検
証データと不具合解決用質問データを提示し、質問に対
する回答の入力を促す。

【００８９】［第２次要求］この場合、ユーザー５が要
求した要求タスクはタスクＡ、要求タイミングは「シス
テムコール「wai_sem」を発行した後」であったとす
る。

【００９０】［処理３］ユーザーインタフェース部１に
戻って、ユーザー５が入力した箇所のデータ１２を、要
求解析部２に転送（ST27）し、要求解析部２に制御を移
す。このとき転送する箇所データ１２は、Ｘ＝６，Ｙ＝
３である。

【００９１】要求解析部２は、比較データ１３を作成し
（ST30）、作成した比較データ１３をタスク動作判定部
３に転送して、制御をタスク動作判定部３に移す。尚、
このときの検証データ１４と比較データ１３を図２２に
示す。

【００９２】タスク動作判定部３は、要求解析部２から
受取った比較データ１３と検証データ１４とを比較し
て、要求タスクの状態を検索する（ST31）。図２２に示
す検証データ１４を検索してみると、要求タイミングで
のタスクＡの状態は、「（セマフォ資源の獲得）待ち」
状態であることが判る（ST32、ST40）。この場合には、
タスクＡの状態を「待ち」から「実行可能」にする必要
がある。その処理を以下に説明する。

【００９３】まず、Ｎの値を判定結果データ１の（１）
欄と不具合解決用質問データの（１）欄に入れる（ST4
5）。ここでは第２次要求であるため、Ｎの値は「２」
である。それぞれの欄に「２」が入る。

【００９４】次に、判定結果データ１の（２）欄に要求
タスクであるタスクＡを入れ、（３）欄にタスクＡの状
態（「待ち」）を入れる（ST46）。

【００９５】次に、この第２次要求の要求タスクＡを
「実行可能」状態に遷移させることができるシステムコ
ールをシステムコール対応テーブル７から検索する（ST
47）。対応するシステムコールは「sig_sem」である。
この「sig_sem」を発行すれば、タスクＢの状態を「待
ち」から「実行可能」に遷移させることができるのであ
る。検索結果の「sig_sem」を不具合解決用質問データ
の（３）欄に入れる（ST48）。

【００９６】次に、不具合解決用質問データの（２）欄
に、タスクＢの状態を「待ち」から「実行可能」に遷移
させるシステムコールである「sig_sem」の発行対象タ
スクを入れる（ST49）。この場合、発行対象タスクはタ
スクＣである。

【００９７】この「wup_tsk 」を「何時」「何処」で発
行するか、ということも機械的には決められない。発行
するタイミング、発行する場所によって、処理が変わっ
てしまうからである。従って、このシステムコール「si
g_sem」を「何時」「何処」で発行するべきなのかをユ
ーザー５に問合せる。

【００９８】この不具合解決用質問データによる問合せ
を第３次要求とする。Ｎに１加算して、ユーザーインタ
フェース部１に制御を戻し（ST50）、ユーザー５に検証
データと不具合解決用質問データを提示し、質問に対す
る回答の入力を促す。

【００９９】［第３次要求］この場合、ユーザー５が要
求した要求タスクはタスクＣ、要求タイミングは「シス
テムコール「ext_tsk」を発行する前」であったとす
る。

【０１００】［処理４］ユーザーインタフェース部１に
戻って、ユーザー５が入力した箇所のデータ１２を、要
求解析部２に転送（ST27）し、要求解析部２に制御を移
す。

【０１０１】要求解析部２は、比較データ１３を作成し
（ST30）、作成した比較データ１３をタスク動作判定部
３に転送して、制御をタスク動作判定部３に移す。尚、
このときの検証データ１４と比較データ１３を図２３に
示す。

【０１０２】タスク動作判定部３は、要求解析部２から
受取った比較データ１３と検証データ１４とを比較し
て、要求タスクの状態を検索する（ST31）。図２２に示
す検証データ１４を検索してみると、要求タイミング
「システムコール「ext_tsk」を発行する前」時点での
タスクＣの状態は、「実行」状態であることが判る（ST
32、ST40）。

【０１０３】このように要求タスクの要求タイミング時
点での状態が「実行」状態である場合には、ひとつ前の
（Ｎ−１の）不具合解決用質問データのシステムコール
を要求タイミング時に発行した場合の検証データ１４を
作成する（ST41）。本実施例でいうと、不具合解決用質
問データのＮ＝２の時のシステムコールである「sig_se
m」をタスクＣが発行した場合の検証データを作成する
ことになる（図２４の検証データを参照）。

【０１０４】次に、第２次要求タスクのイベントの最後
の時点での状態を検証データ１４から検索する（ST42、
ST43）。

【０１０５】検索の結果、第２次要求タスクＡは「実
行」状態に遷移している。判定結果データ１のタスクＡ
の状態を「実行」状態に書きかえる（ST44）。

【０１０６】これで、第２次要求タスクの状態が「実
行」状態に遷移したことで、第３次要求は満たされた。
しかし、第１要求のタスクＢは依然として「実行可能」
状態のままであるため、ここまで作成した検証データ、
判定結果データ、不具合解決用質問データ（第１次分）
をユーザーインタフェース部１に転送し、制御をユーザ
ーインタフェース部１に戻す（ST38〜39）。

【０１０７】そして、これまで説明した処理に準じて、
第１次要求のタスクＢが第１次要求タイミングである
「イベントの最後」の時点で「実行」状態に遷移するま
で、処理を繰り返す。このタスクＢが「イベントの最
後」の時点で「実行」状態に遷移するまでの検証デー
タ、比較データ、判定結果データ１、判定結果データ
２、及び不具合解決用データの状態を、図２１〜図２６
に示す。

【０１０８】図２６に示した検証データが本来のプログ
ラムの仕様を満たすものであり、同じく図２６に示した
判定結果データ１，２と不具合解決質問データが今回の
不具合の要因となっていたものである。本発明の情報処
理装置は、これらの各データをユーザー５に提示するこ
とで、プログラムの不具合要因とその解決策を対話形式
でユーザーに提示できる。

【０１０９】また、処理終了時には、第１実施例と同様
にして、図２６の検証データからプログラムのスケルト
ンを自動生成し、ユーザー５に提供することができる。

【０１１０】以上、第１実施例及び第２実施例を用いて
説明したように、本発明の不具合解析プログラムを格納
したコンピュータ読み取り可能な記憶媒体を搭載した情
報処理装置を用いることにより、対話形式で不具合要因
とその解決策を容易に特定でき、更に、本来の仕様に沿
ったプログラムの動作、及び本来の仕様に沿ったプログ
ラムをも容易に取得することができる。

【０１１１】つまり、対話形式でユーザーから指摘され
た不具合箇所とプログラムの実行履歴情報から不具合要
因とその解決策を特定し、更にこの解決策を反映させた
プログラムの動作をユーザーに提示することができる。

【０１１２】また、前記特定した不具合要因とその解決
策から、上記不具合を解決したプログラムを自動生成し
てユーザーに提示することができる。

【０１１３】その結果、プログラムの不具合解析作業を
容易にし、従来不具合解析に要していた時間を短縮する
ことができ、プログラムの開発コストや開発期間などを
低減することができる。

【０１１４】（第３実施例）本発明に係るアプリケーシ
ョンプログラム開発支援システムの実施形態について説
明する。なお、本実施形態では、あるマイコン向けの組
込み用リアルタイムＯＳ（μＩＴＲＯＮ３．０仕様）に
対応したアプリケーションプログラムを開発する場合を
例に説明する。

【０１１５】［ハードウェア資源の構成］図２７は、本
実施形態に係るアプリケーション開発システム２０を実
施するためのハードウェア資源の構成を示す概観図であ
る。

【０１１６】図２７に示すように、ハードウェア資源
は、中央処理装置（ＣＰＵ）５１と、ＲＡＭ５２とを備
えている。なお、本実施形態では、中央処理装置（ＣＰ
Ｕ）５１、ＲＡＭ５２は、バス５８を介して、ＲＯＭ５
３、通信装置５４、補助記憶装置５５、表示装置５６、
入力装置５７及び出力装置５９に接続されている。

【０１１７】ＲＯＭ５３や補助記憶装置５５には、コン
ピュータ・プログラムのコードが記録されている。この
コンピュータ・プログラムは、アプリケーション開発シ
ステム２０上のオペレーティングシステムと協働して中
央処理装置５１等に命令を与えるものである。コンピュ
ータ・プログラムコードは、ＲＡＭ５２にロードされる
ことによって実行される。なお、このコンピュータ・プ
ログラムのコードは、圧縮され、または、圧縮したコー
ドも含め、複数に分割して、複数の媒体にまたがって記
録することもできる。

【０１１８】また、本実施形態において、アプリケーシ
ョン開発システム２０へのデータの入出力をするユーザ
・インターフェース・ハードウェアとしては、画面位置
情報、文字情報を入力するための入力装置５７や、画像
データをユーザに提示するための表示装置５６、出力装
置５９がある。入力装置５７としては、例えば、ポイン
ティングデバイスやキーボード等がある。この他、デー
タの入出力の方法としては、通信装置５４を介して他の
コンピュータ等から入力データを受け取ることや、また
補助記憶装置５５などの媒体から行うものが挙げられ
る。また、表示装置５６は、モニターやプリンターな
ど、データを可視化して出力するものである。

【０１１９】このように、アプリケーション開発システ
ム２０は、パーソナルコンピュータやワークステーショ
ン、携帯情報端末、ネットワークコンピュータ上におけ
る実施、あるいはこれらの組合せによるハードウェア構
成での実施も可能である。ただし、これらのハードウェ
ア構成は例示であり、全ての構成要素がアプリケーショ
ン開発システム２０の必須の構成要素となるものではな
い。

【０１２０】［アプリケーション開発システムの構成］
上述したハードウェア構成によりアプリケーション開発
プログラムを実行することによって、かかるハードウェ
ア構成上に本発明のアプリケーション開発システムが仮
想的に構築される。図２８は、本実施形態において構築
されたアプリケーション開発システムの構成を模式的に
示すブロック図である。

【０１２１】同図に示すように、本実施形態に係るアプ
リケーション開発システムは、環境定義部３１と、プロ
グラミング部３２と、テンプレートファイル生成部４０
と、環境定義ファイル生成部４３と、チェック部４５
と、実行オブジェクト部４６と、表示情報作成部４８と
を有している。

【０１２２】環境定義部３１は、入力された環境定義デ
ータを解析し、解析した結果をプログラミング部３２に
供給するものである。この環境定義データには、開発す
るアプリケーションシステムが利用するＲＴＯＳ管理下
のオブジェクト数や、その初期化設定、開発アプリケー
ションシステムが稼働するマイコンに発生する外部／内
部割り込み要因に対する初期化データ等が含まれる。ま
た、この環境定義部３１は、解析結果から環境定義情報
４９を生成する。環境定義情報は、環境定義ファイルを
生成する際には、環境定義ファイル生成部４３に入力さ
れる。

【０１２３】プログラミング部３２は、入力装置７を介
して行われるプログラミング操作により開発プログラム
を構築するものである。

【０１２４】テンプレートファイル生成部４０は、プロ
グラミング部３２からテンプレートファイル生成の命令
を受け取り、プログラミング情報３８の情報を基に、テ
ンプレートファイル４２を生成し、出力するものであ
る。

【０１２５】また、環境定義ファイル生成部４３は、入
力された環境定義データをファイル形式に形成するもの
である。

【０１２６】チェック部４５は、環境定義データに基づ
いて開発対象であるアプリケーションプログラムを実行
させる実行環境の動作規則に従い、仮想的に構築し、こ
の仮想環境の下で開発プログラムの動作チェックを行う
ものである。具体的には、本実施形態では、システムコ
ール選択チェック部５０と、システムコール発行位置チ
ェック部３５と、システムコール操作対象位置チェック
部３６と、ＲＴＯＳカーネルチェック部３７とを有して
いる。

【０１２７】システムコール選択チェック部５０は、選
択されたシステムコールが、プログラミングの対象とな
る動作環境下において、現実に発行しうるか 否かにつ
いて判断するものである。

【０１２８】システムコール発行位置チェック部３５
は、システムコールを発行すると仮定した位置、もしく
はタイミングが、システムコールを現実に発行するもの
か否かについて判断するものである。

【０１２９】システムコール操作対象位置チェック部３
６は、システムコールを発行すると仮定した対象につい
て、システムコールが現実に発行した場合に、操作でき
るのか否かについて判断するものである。

【０１３０】ＲＴＯＳカーネルチェック部３７は、本実
施形態に係るハードウェア資源上で動作するＯＳである
ＲＴＯＳの動作について、確認するものである。

【０１３１】また、前記実行オブジェクト部４６は、開
発されたプログラムをコンパイルし、実行オブジェクト
ファイル（電子ファイル）として出力するものである。
前記表示情報作成部４８は、モニター等の表示装置６等
において出力可能に、各情報を生成するものである。

【０１３２】［ＧＵＩ（Graphical User Interface）の
構成］次いで、プログラミング装置３２のインタフェー
スであるＧＵＩ（Graphical User Interface）の構成に
ついて説明する。図２９及び図３０は、表示装置６に表
示された画面構成を示すものである。

【０１３３】このＧＵＩは、表示装置６に、ウインドウ
７０として表示され、このウインドウ７０は、プログラ
ム中において発行したいシステムコールを選択するシス
テムコール選択ペイン６１と、プログラム中において利
用可能な実行環境提供の資源オブジェクト、およびＲＴ
ＯＳ管理下のオブジェクト（以下「オブジェクト」とい
う。）／割り込み要因別にグループ別に表示するオブジ
ェクト表示ペイン６２と、プログラミングを行うプログ
ラミング作業ペイン６３とを有している。

【０１３４】プログラミング作業ペイン６３には、シス
テムコール発行位置（オブジェクト）、操作位置（オブ
ジェクト）を指定するために各オブジェクト毎に設けら
れたシーケンスライン６４と、プログラム中における、
理論的なシステムコール発行タイミングや、発行順を定
める目盛りペイン６５がインタフェースとして備えられ
ている。

【０１３５】なお、プログラミング作業ペイン６３は、
タスク部のプログラミングを行うタスク部プログラミン
グ作業ペインと、タスク独立部別に、タスク独立部のプ
ログラミングを行うハンドラ部プログラミング作業ペイ
ンから構成される。

【０１３６】そして、プログラミング装置３２が起動さ
れた際に取得された環境定義情報４９は、図３０に示す
ように、オブジェクト表示ペイン６２に表示される。

【０１３７】オブジェクト表示ペイン６２は、プログラ
ム中において利用可能なオブジェクト／割り込み要因を
表示するタスクオブジェクトグループ８２を有してい
る。このタスクオブジェクトグループ８２では、周期起
動ハンドラグループ８５などのグループ分けがなされて
おり、各グループに属する個々のオブジェクトにはオブ
ジェクト名８３と、初期状態設定が行われている場合
は、オブジェクト初期情報８４が併せて表示される。な
お、未定義オブジェクトに関しては、オブジェクトグル
ープ名だけが表示される。

【０１３８】すなわち、例えば、図中タスクオブジェク
ト＿ｕｓｒ３ｃｄのオブジェクト初期情報は、”ＩＤ”
がタスクＩＤ情報を意味し、”Ｐｒｉ”がタスク優先度
情報を意味し、”１ｓｔ”が初期起動タスク情報（アプ
リケーションプログラム処理において、最初、実行状態
タスクであることを意味する。）を意味する。つまり、
本実施形態では、プログラミング作業ペイン６３におい
て、プログラミングを始める場合は、＿ｕｓｒ３ｃｄが
最初にシステムコール発行を行う。

【０１３９】また、本実施形態において、システムコー
ル発行操作は、システムコール選択ペイン６１から、発
行するシステムコールを選択した後に、目盛りペイン６
５にある目盛り１つに、１つのシステムコールを、その
目盛り位置における実行状態タスクのシーケンスライン
６４上に置くことにより行う。

【０１４０】これによりシステムコール発行位置を仮定
することができる。プログラミングは、目盛り位置：０
を起点として構築し、プログラム処理は目盛り位置：０
から順に行われる。また、本実施形態において、この目
盛りペイン６５には、目盛り間を開けてシステムコール
を発行することを防ぐ機能が装備されている。

【０１４１】発行したシステムコールが、操作対象オブ
ジェクト指定を必要とする場合は、操作対象オブジェク
トが有するシステムコール発行位置と同一目盛り位置の
シーケンスライン６４上を指定する。この位置が、シス
テムコール操作対象位置と仮定される。システムコール
操作対象位置選択時、システムコール発行位置とは違う
目盛り位置を選択できない機能を装備している。

【０１４２】システムコール発行の操作には、発行時の
プログラミング作業ペイン６３において、発行可能目盛
りの最大値に発行する追加操作、プログラミング作業ペ
イン６３にある発行済みシステムコールの位置に対する
システムコール挿入発行操作、発行済みシステムコール
に対する削除操作、発行目盛り位置移動操作（複数のシ
ステムコール発行がある場合）、システムコール種別変
更操作、システムコール引数変更操作、システムコール
操作対象位置移動等の編集機能が設けられている。

【０１４３】［アプリケーション開発システムの処理手
順］そして、上述したアプリケーション開発システム２
０は、以下のように動作する。図３１は、本実施形態に
係るアプリケーション開発システム２０の動作を示すフ
ロー図である。

【０１４４】先ず、最初に必要なデータとして、入力装
置５７から環境定義装置３１に対し、環境定義データを
入力する（Ｓ１０１）。

【０１４５】環境定義装置３１に必要なデータが揃う
と、入力装置５７から環境定義装置３１に対し、プログ
ラミング装置３２を起動する情報を入力する。入力を受
け付けた環境定義装置３１は、プログラミング装置３２
を起動する（Ｓ１０２）。この起動の際、プログラミン
グ装置３２のインタフェースであるＧＵＩ（GraphicalU
ser Interface）が、表示装置５６に表示される。

【０１４６】プログラミング装置３２は、起動された
後、入力装置５７からプログラミング操作入力を待つ。
ユーザーは、入力装置５７を介してプログラミング操作
によりプログラミングデータの入力を行う（Ｓ１０
３）。

【０１４７】次いで、入力されたプログラムについて、
チェック部４５によりプログラミング情報のチェックを
行う（Ｓ１０４）。

【０１４８】そして、チェックの結果がエラーであるか
否かの判定を行い（Ｓ１０５）、エラーである場合には
エラー情報４１を更新するとともに、そのエラーの内容
について表示情報作成部４８により表示情報を作成し、
表示装置５６において表示する。ステップＳ１０５にお
いて、エラーが発生していないと判断された場合には、
プログラミング情報３８及びオブジェクト情報３９を保
存する（Ｓ１０６及びＳ１０７）。

【０１４９】その後、プログラミングを終了するか否か
の選択を待ち（Ｓ１０８）、プログラミングを続行する
場合には、ステップＳ１０３に戻り、再度プログラミン
グデータの入力を受け付ける。ステップＳ１０８におい
て、プログラミングの終了を選択した場合には、テンプ
レートファイル生成部４０においてテンプレートファイ
ル４２を生成し、出力するとともに（Ｓ１１０）、実行
オブジェクト生成部４６において、実行オブジェクトフ
ァイル４７を生成し、出力し（Ｓ１１１）、作業を終了
する（Ｓ１１２）。

【０１５０】プログラミングデータの入力を受け付けて
から、入力結果を表示するまでの処理手順を図３２に示
す。この処理手順に沿って、表示装置５６に表示されて
いるウインドウ７０をインタフェースとするプログラミ
ングを行う。

【０１５１】次いで、発行されるシステムコールを、シ
ステムコール選択ペイン６１で入力装置７を通じて選択
する（Ｓ２０１）。また、入力装置５７を通じて、シス
テムコールが発行する位置を入力する（Ｓ２０２）。

【０１５２】入力されたこれらのデータに基づいてシス
テムコール発行位置チェック部において、システムコー
ル発行位置をチェックする（Ｓ２０３）。

【０１５３】次いで、このチェック結果について判定を
行い、エラーが発生していない場合には、発行システム
コールの操作対象の選択が必要か否かの選択を要求する
（Ｓ２０５）。捜査対象の選択が不要である場合には、
ＲＴＯＳカーネルチェック装置にて、発行システムコー
ルカーネル部を処理する（Ｓ２０１）。

【０１５４】ステップＳ２０５において発行システムコ
ールの操作対象の選択が必要である場合には、入力装置
５７を介して、プログラミング操作システムコール操作
外傷位置を入力する（Ｓ２０７）。

【０１５５】システムコール操作対象位置チェック部３
６にて、システムコール操作対象位置をチェックする
（Ｓ２０７）。このチェック結果の内容についてエラー
が生じているか否かについて判定を行い（Ｓ２０８）、
エラーが生じていない場合には、入力装置７によりプロ
グラミング操作のシステムコール引数を入力し（Ｓ２０
９）、ＲＴＯＳカーネルチェック部３７にて、発行シス
テムコールカーネル部を処理する（Ｓ２１０）。

【０１５６】ステップＳ２１０において発行システムコ
ールカーネル部を処理した後、カーネル処理の内容を判
定する（Ｓ２１１）。このステップＳ２１１においてエ
ラーが発生していない場合には、プログラミング情報３
８の保存（Ｓ２１２）及びオブジェクト情報３９の保存
（Ｓ２１３）を行い、表示情報作成部４８にて表示情報
を作成し（Ｓ２１４）、作成結果を表示装置５６におい
て表示し（Ｓ２１５）、終了する。

【０１５７】なお、ステップＳ２０４やＳ２０８、Ｓ２
１１においてエラーが生じた場合には、エラー情報４１
を保存した後（Ｓ２１６）、このエラー情報を表示し
（Ｓ２１５）、処理を終了する。

【０１５８】［システムコール発行時の動作］次いで、
システムコール時の動作について説明する。ここでは、
プログラミング作業ペイン６３がタスク部になっている
と仮定し、実行状態タスクである”＿ｕｓｒ３ｃｄ”が
システムコール“ｓｔａ＿ｔｓｋ”を発行し、休止状態
タスクである”＿ｕｓｒ６ｃｄ”を起動する追加操作を
例に説明する。図３３は、システムコール時における表
示装置５６に表示された画面構成を示す説明図である。

【０１５９】まず、前述したシステムコール選択ペイン
６１から、発行するシステムコールを選択する。この選
択操作時、システムコール選択チェック部５０が、プロ
グラミング作業ペイン６３をタスク部に仮定している場
合は、タスク部から発行可能なシステムコールを選択可
能にし、ハンドラ部に仮定している場合は、ハンドラ種
別により、そのハンドラから発行可能なシステムコール
が選択可能となるように、ユーザのシステムコール選択
操作を監視している。

【０１６０】本実施形態では、プログラミング作業ペイ
ン６３がタスク部と仮定しているため、システムコール
ペイン６１からハンドラ部からのみ発行可能なシステム
コールを選択することはできない。

【０１６１】入力装置７から、システムコール選択ペイ
ン６１より“ｓｔａ＿ｔｓｋ”を選択する。選択後、プ
ログラミング作業ペイン６３において、入力装置５７か
らシステムコール発行操作を行う。この時点において、
システムコールを発行するメモリ位置は、発行済みシス
テムコールが存在しないため「０」であり、メモリ位
置：０における実行状態タスクは”＿ｕｓｒ３ｃｄ”で
あるため、”＿ｕｓｒ３ｃｄ”タスクのシーケンスライ
ン６４上付近（シーケンスライン上付近とは、対象シー
ケンスラインの上、あるいは下のシーケンスラインから
対象シーケンスラインに近い位置までとする）システム
コール発行位置９１を入力装置７から選択する。

【０１６２】この追加操作におけるシステムコール発行
位置の選択は、先の説明の通り、目盛り間を開けてシス
テムコールを発行することを防ぐ機能が働く。機能は、
図３０のようにシステムコール発行選択位置９１が指す
場所を指定しなくても、目盛り位置：０以降、”＿ｕｓ
ｒ３ｃｄ”のシーケンスライン６４上付近を選択すれ
ば、目盛り位置：０を選択したことになる。

【０１６３】選択（入力）を受け付けたプログラミング
装置３２は、システムコール発行位置チェック装置３５
に、選択内容をチェックさせる。システムコール発行位
置チェック装置３５では、図３４の処理手順によりチェ
ックを行う。

【０１６４】すなわち、図３４に示すように、先ずシス
テムコール発行位置におけるオブジェクトの種別を判定
し（Ｓ３０１）、”ＯＫ”であれば、システムコール発
行位置におけるオブジェクトの状態について判断する
（Ｓ３０２）。このステップＳ３０２において”ＯＫ”
であるときは、戻り値「ret」に、システムコールが操
作対象オブジェクトを必要とするか、しないかについて
の情報を与えて（Ｓ３０３）、処理を終了する。

【０１６５】この戻り値「ret」は、システムコールが
操作対象オブジェクトを必要とするか、いないかの情報
と、エラー情報をセットするものである。本実施形態で
は、この戻り値「ret」は、３２bit領域を持つ変数であ
り、最上位ビットにはシステムコールが操作対象オブジ
ェクトを必要とするか、しないかの情報がセットされ、
それ以外のビットにはエラー情報がセットされる領域に
用いられている。

【０１６６】ステップＳ３０１またはステップＳ３０２
において”ＮＧ”と判断されたときには、戻り値「re
t」に、エラー情報を与え、前記ステップＳ３０３を経
て、処理を終了する。

【０１６７】そして、このようにして得られた戻り値
「ret」により、発行したシステムコールが“ｓｔａ＿
ｔｓｋ”であり、プログラミング装置３２は、システム
コール発行位置チェック装置３５が設定した、ｒｅｔ情
報領域のチェック結果から、チェック判定にエラーが無
いことと、“ｓｔａ＿ｔｓｋ”に操作対象オブジェクト
を必要とすることが判明する。その操作対象タスクは”
＿ｕｓｒ６ｃｄ”であるため、”＿ｕｓｒ６ｃｄ”タス
クのシーケンスライン６４上付近システムコール発行位
置９１‘を入力装置２７から選択する。

【０１６８】もし、システムコール発行位置９１が図３
３と違う場所、例えば、周期起動ハンドラオブジェクト
である”ｃｙｃ＿Ｈｄｒｌ”のシーケンスライン６４付
近をシステムコール発行位置として選択した場合には、
システムコール発行位置チェック装置３５では、ＲＴＯ
Ｓ仕様から“ｓｔａ＿ｔｓｋ”発行位置オブジェクトと
して不適と判断し、ｒｅｔ情報領域にエラー情報を与え
る。

【０１６９】また、システムコール発行位置９１以外の
タスクオブジェクトのシーケンスライン６４付近をシス
テムコール発行位置として選択した場合は、システムコ
ール発行位置チェック装置３５では、ＲＴＯＳ仕様から
システム発行タスクの状態不適（実行状態タスクではな
い）と判断し、ｒｅｔ情報領域にエラー情報を与える。

【０１７０】システムコール操作対象位置選択は、シス
テムコール発行位置からマウス等の入力装置によるドラ
ッグ操作で位置を選択する。この際に、先に述べた様
に、システムコール操作対象位置は、システムコール発
行位置と同一目盛り位置のシーケンスライン上付近を選
択させる機能があり、その機能は、図３３中の表示ライ
ン９３のように、システムコール発行位置からのドラッ
グ操作に、カーソルの縦方向移動にのみ線が追従描画さ
れ、その線の末端が選択位置となる様になっている。

【０１７１】選択（入力）を受け付けたプログラミング
装置３２は、システムコール操作対象位置チェック装置
３６に、選択内容をチェックさせる。システムコール操
作対象位置チェック装置３６では、図３５の処理手順に
よりチェックを行う。

【０１７２】すなわち、図３５に示すように、先ず、シ
ステムコール操作対象位置のシステムコール操作対象位
置におけるオブジェクトの種別を判定し（Ｓ４０１）、
ここにおいて”ＯＫ”であれば、システムコール操作対
象位置におけるオブジェクトの状態について判断する
（Ｓ４０２）。このステップＳ４０２において”ＯＫ”
であるときは、戻り値「ret」の最上位ビット領域をク
リアしてその値を「０」とし（Ｓ４０３）、処理を終了
する。

【０１７３】ステップＳ３０１またはステップＳ３０２
において”ＮＧ”と判断されたときには、戻り値「re
t」に、エラー情報を与え、前記ステップＳ３０３を経
て、処理を終了する。

【０１７４】これらの処理により、この戻り値「ret」
の最上位ビットにセットされたシステムコールが操作対
象オブジェクトを必要とするかしないかの情報がクリア
され、それ以外のビットにはエラー情報がセットされる
こととなる。

【０１７５】チェックにおいても、システムコール発行
位置のチェックと同じく、システムコール操作対象位置
９１’が図３３と違う場所、例えば、周期起動ハンドラ
オブジェクトである”ｃｙｃ＿Ｈｄｒｌ”のシーケンス
ライン６４付近をシステムコール操作対象位置として選
択した場合は、システムコール操作対象位置チェック装
置３６では、ＲＴＯＳ仕様から“ｓｔａ＿ｔｓｋ”操作
対象オブジェクトとして不適と判断し、ｒｅｔ情報領域
にエラー情報を与える。

【０１７６】また、システムコール操作対象オブジェク
トが９１’以外のタスクオブジェクトのシーケンスライ
ン６４付近をシステムコール操作対象位置として選択し
たが、選択したタスクが休止状態タスクでない場合は、
システムコール操作対象位置チェック装置３６では、Ｒ
ＴＯＳ仕様からシステムコール操作対象タスクの状態不
適と判断し、ｒｅｔ情報領域にエラー情報を与える。

【０１７７】システムコール操作対象選択位置のチェッ
クが終了し、エラーが無い場合は、発行したシステムコ
ールが持つ機能の処理をＲＴＯＳカーネルチェック装置
３７にて行う。本実施例においては、休止状態である”
＿ｕｓｒ６ｃｄ”を、実行可能状態にする。この処理に
おけるエラー判定基準は、ＲＴＯＳ仕様に基づく。

【０１７８】システムコール発行の操作、そのチェック
完了後、プログラミング装置３２は、ウインドウ７０に
発行結果を追加描画するために、プログラミング情報３
８、オブジェクト情報３９を更新し、表示情報作成装置
４８にて表示情報を作成し、表示装置６に、図３６の様
な描画更新されたウインドウ７０が表示される。

【０１７９】プログラミング情報３８には、目盛り位
置：０に発行されたシステムコールと、その発行内容が
情報として保存される。

【０１８０】オブジェクト情報３９には、目盛り位置：
０に発行されたシステムコールの影響により、オブジェ
クトがどの様に変化したか、変化したオブジェクト情報
だけを更新する。

【０１８１】オブジェクト情報３９を利用し、プログラ
ミング装置３２は、オブジェクト情報内容３９に変更が
ある／ないに関わらず、更新処理終了後、オブジェクト
情報３９から、次の目盛り位置における実行状態タスク
情報を検出する。その情報を実行状態ナビゲートライン
１００として図３６の様に、発行したシステムコールの
システムコール発行位置から次の目盛り位置まで線描画
する。

【０１８２】また、入力装置５７のマウス等の操作ポイ
ントを、プログラミング作業ペイン６３内にある、発行
済みシステムコールの描画を外し、あるオブジェクトが
持つシーケンスライン６４上付近に移動させると、操作
ポイントが指したプログラム処理の流れの中において、
そのオブジェクトの状態をウィンドウ７０に表示させ、
参照することができる。

【０１８３】プログラミング装置３２起動後、入力装置
５７から入力した操作によって“ｓｔａ＿ｔｓｋ”発行
のプログラミングが完了する。この装置を利用すること
により、システムコール発行の内容を開発装置に実装さ
れているチェック装置群４５が、利用するＲＴＯＳ仕様
に従ったチェックと、ＲＴＯＳ管理下のオブジェクト操
作を行うため、プログラミングの段階において、システ
ムの不具合除去、不具合検知を行うことが可能となり、
オブジェクト情報３９の利用により、プログラミング段
階において、タスクオブジェクトの状態遷移の表示、他
アプリケーションシステムにおいて使用するオブジェク
トの状態を表示することにより、プログラミングを強力
にサポートすることができる。

【０１８４】［イベント発生時の動作］次いで、イベン
ト発生時の動作について説明する。ここでは、アプリケ
ーション開発システム２０において、図３７の様なプロ
グラミングを入力装置５７から入力が行われた場合を例
に説明する。図３７は、本発明装置によるプログラミン
グ中の状態である。

【０１８５】本実施例では、開発アプリケーションシス
テムが稼働するハードウェアにおいて、ハードウェアの
周期的な割り込み、非同期な割り込みイベントの発生
時、その割り込みイベントに連動し処理される単位をプ
ログラミングした場合に、プログラミングの段階におい
て、その割り込みイベント発生のタイミングを定義し、
アプリケーションプログラムが使用するタスクの振る舞
い、およびオブジェクトの状態変化を検証する方法を示
す。

【０１８６】図３７に示すように、タスク部プログラミ
ング作用ペイン１１１では、タスク部のプログラミング
が行われており、ｃｙｃ＿Ｈｄｒｌハンドラ部プログラ
ミング作業ペイン１１２では、タスク独立部であるｃｙ
ｃ＿Ｈｄｒｌハンドラ内にプログラミングを、それぞれ
別の作業ペインで行っている。

【０１８７】タスク独立部は、ハードウェアの周期的な
割り込み、非同期な割り込みイベント発生時の処理単位
であり、タスク部のプログラミングと同期が取られてい
ない。

【０１８８】本実施形態では、図３８の様に、アプリケ
ーションプログラミング構築段階において、タスク独立
部である周期起動ハンドラ部の処理単位をタスク部のプ
ログラム中に仮想的に処理させる、割り込み発生イベン
トを発行することにより、ハードウェアの周期的な割り
込み、非同期な割り込みイベントが発生した場合のシミ
ュレーションを検証することができる。

【０１８９】割り込み発生イベントを発行し、ハードウ
ェアの周期的な割り込み、非同期な割り込みイベントの
発生シミュレーションを検証するためには、まず、タス
ク部のプログラミング作業ペインにおいて、割り込みイ
ベントを発生させたい目盛り位置に、割り込み発生イベ
ントを発行する。入力装置５７により割り込み発生イベ
ント発行が行われ、入力を受け付けたプログラミング装
置３２は、システムコール発行時に行うチェックを同様
に行う。チェック内容は、割り込み発生イベント発行位
置のオブジェクト種別、オブジェクトの状態である。

【０１９０】割り込みイベントを発生させるオブジェク
トの状態は、環境定義装置３１に対し、静的に定義する
そのオブジェクトに必要なシステム環境定義と、そのオ
ブジェクトの機能を有効／無効にする操作があり、その
様な操作が必要な場合のみ入力装置５７から、プログラ
ミング装置３２に対し、そのオブジェクトの動的な操作
「システムコール発行」を行う。

【０１９１】プログラミング装置３２が、割り込み発生
イベントの発行が正しいものであると判断した場合、図
３８の処理手順に従い、割り込み発生イベントを発行し
たハンドラ内のプログラミング処理をすべて行い、その
処理の結果、オブジェクトの変化をオブジェクト情報３
９に保存し、タスク部の処理に戻ることになる。アプリ
ケーションプログラムの処理イメージを、図４０に示
す。

【０１９２】すなわち、ハンドラ内に行われたプログラ
ムを処理するには、図３９に示すように、先ずプログラ
ミング情報３８に保存されている、ハンドラ内の目盛り
位置：０のプログラミング情報から、一つ一つ順番に読
み込む（Ｓ５０１）。次いで、有効情報の有無を判断し
（Ｓ５０２）、ハンドラ内のプログラミング情報が無
い、あるいは有効情報をすべて処理し終えた場合には、
オブジェクト情報３９を保存し（Ｓ５０４）、終了す
る。

【０１９３】ステップＳ５０２において、有効情報があ
る場合には、ＲＴＯＳカーネルチェック部３７にて、発
行システムコールカーネル部を処理し（Ｓ５０３）、ス
テップＳ５０１以降の処理を繰り返す。

【０１９４】この様な方法により、割り込みイベントを
発生させたいオブジェクトの状態を操作し、オブジェク
トの状態が割り込み発生できる状態であることをチェッ
ク群４５により判定された場合に、タスク部のプログラ
ミング中に、同期がとれてないハンドラ部のプログラミ
ング処理単位を割り込みイベントとして、一つのアプリ
ケーションシステムの動作として表示することができる
ため、プログラミングの段階において、ハードウェアに
発生する周期的な割り込み、非同期な割り込みを検証し
ながら、作業をすすめることができる。

【０１９５】［時間待ち状態における動作］次いで、時
間待ち状態における動作について説明する。ここでは、
アプリケーション開発システム２０において、図４０及
び図４１に示すようなプログラミングを入力装置７から
入力が行われた場合を例に説明する。図４０及び図４１
は、本発明装置によるプログラミング中の状態における
画面操作を示す説明図である。

【０１９６】本実施形態では、開発アプリケーションシ
ステムが稼働するハードウェアにおいて、ハードウェア
が実装している時間機能をＲＴＯＳが利用し、ある実行
状態のタスクを時間待ち状態に遷移させ、プログラミン
グの段階において、その待ち時間の解除タイミングを定
義し、アプリケーションプログラムが使用するタスクの
振る舞い、及びオブジェクトの状態変化を検証する方法
を示す。

【０１９７】図４１のタスク部プログラミング作業ペイ
ン１１１では、目盛り位置：１において、“ｄｌｙ＿ｔ
ｓｋ”（タスク遅延）システムコールが発行されてい
る。“ｄｌｙ＿ｔｓｋ”を発行した実行タスク”＿ｕｓ
ｒ３ｃｄ”は、時間待ち状態へと遷移する。

【０１９８】アプリケーションプログラムの実行環境か
ら、時間待ち状態タスク＿ｕｓｒ３ｃｄの待ちを解除す
る方法は、“ｒｅｌ＿ｗａｉ”［他タスクの待ち状態解
除］を任意の目盛り位置で発行するか、“ｄｌｙ＿？ｔ
ｓｋ”発行時に指定した遅延時間の時間経過を待つこと
になる。“ｒｅｌ＿ｗａｉ”を任意のタイミングで発行
し、時間待ち状態を解除する方法は、システムコール発
行時の動作で説明した機能により実現できる。

【０１９９】もう一つの時間経過を待つ方法は、開発ア
プリケーションシステムが稼働するハードウェアにおい
て、ハードウェアが実装している時間機能を利用してい
るため、プログラミング段階において、動作を検証する
ことができない。そこで、タイムアウトイベントを任意
のタイミングで、実行状態タスクから発行する。

【０２００】タイムアウトイベントの発行は、上述した
システムコールの発行方法と同じである。つまり、タイ
ムアウトを発行するタスク側がシステムコール発行位置
であり、操作の対象となるオブジェクトが、時間待ち状
態タスクとなる。

【０２０１】図４１に示す例では、目盛り位置：１で時
間待ち状態に遷移し、目盛り位置：９においてタイムア
ウトイベント１３１を発行し、”＿ｕｓｒ３ｃｄ”の時
間待ち状態を解除している。実施例では、時間待ち状態
を解除したことにより、タスクオブジェクト状態が変化
し、目盛り位置：１０において、実行状態タスクが”＿
ｕｓｒ３ｃｄ”になることが検証できている。

【０２０２】以上、第３実施例を用いて説明したよう
に、本発明によれば、プログラミング段階において、そ
の実行環境の動作規則に従いアプリケーションシステム
の振る舞いを視覚的に確認し、早期にプログラミングの
不整合発見を行い、作業行程の戻りを低減させることに
より、効率的なアプリケーションシステム開発を可能と
することができる。

【０２０３】以上、本発明について、詳細に説明した
が、本発明は本実施例に限定されず、本発明の主旨を逸
脱しない範囲において、種々の改良や変更を成し得るで
あろう。例えば、本実施例では、イベントの最後（プロ
グラムの処理終了時点）のタスクの状態に着目して不具
合要因を解析する例を示したが、この着目するポイント
はこれに限定されず、ユーザーは任意のポイントに着目
して不具合要因の解析することができる。

【０２０４】また、本実施例ではＩＴＲＯＮに準拠した
アプリケーション・プログラムを例に説明したが、本発
明はこのようなリアルタイムＯＳに限定されず、一般に
マルチタスク方式で動作するプログラムに広く適用でき
る。

【０２０５】

【発明の効果】本発明によれば、対話形式でユーザーか
ら指摘された不具合箇所とプログラムの実行履歴情報か
ら不具合要因とその解決策を特定し、更にこの解決策を
反映させたプログラムの動作をユーザーに提示すること
ができる。また、前記特定した不具合要因とその解決策
から、該不具合を解決したプログラムを自動生成してユ
ーザーに提示することができる。

【０２０６】これらの結果、プログラムの不具合解析作
業を容易にし、従来不具合解析に要していた時間を短縮
することができ、プログラムの開発コストや開発期間な
どを低減することができる。

【０２０７】また、他の発明によれば、プログラミング
段階において、その実行環境の動作規則に従いアプリケ
ーションシステムの振る舞いを視覚的に確認し、早期に
プログラミングの不整合発見を行い、作業行程の戻りを
低減させることにより、効率的なアプリケーションシス
テム開発を可能とすることができる。

【図面の簡単な説明】

【図１】本発明に係る情報処理装置の一実施例を示す概
略図である。

【図２】本発明に係る情報処理装置に搭載される不具合
解析プログラムを格納したコンピュータ読み取り可能な
記憶媒体の処理例を示す流れ図である。

【図３】本発明の情報処理装置が利用する検証データの
フォーマット例を示す概略図である。

【図４】本発明の情報処理装置が利用する比較データの
フォーマット例を示す概略図である。

【図５】本発明の情報処理装置が利用する判定結果デー
タ１のフォーマット例を示す概略図である。

【図６】本発明の情報処理装置が利用する判定結果デー
タ２のフォーマット例を示す概略図である。

【図７】本発明の情報処理装置が利用する不具合解決用
質問データのフォーマット例を示す概略図である。

【図８】第１実施例で想定したアプリケーション・プロ
グラムの仕様に沿った動作状況を示す入出力関連図であ
る。

【図９】第１実施例で想定したアプリケーション・プロ
グラムの不具合による動作状況を示す入出力関連図であ
る。

【図１０】図２で示した不具合解析プログラムを格納し
たコンピュータ読み取り可能な記憶媒体の処理のうち、
ユーザーインターフェース部の詳細な処理例を示す流れ
図である。

【図１１】図１０で示したプログラムの動作状況をユー
ザーに提示した表示例示すイメージ図である。

【図１２】図２で示した不具合解析プログラムを格納し
たコンピュータ読み取り可能な記憶媒体の処理のうち、
要求解析部の詳細な処理例を示す流れ図である。

【図１３】図１０で示したプログラムの動作状況をユー
ザーに提示した表示例示すイメージ図である。

【図１４】図２で示した不具合解析プログラムを格納し
たコンピュータ読み取り可能な記憶媒体の処理のうち、
タスク動作判定部の詳細な処理例を示す流れ図である。

【図１５】図１０で示したプログラムの動作状況をユー
ザーに提示した表示例示すイメージ図である。

【図１６】本発明の情報処理装置が利用するシステムコ
ール対応テーブルの一例を示す概略図である。

【図１７】第１実施例における各種データの状態を示し
た図である。

【図１８】第１実施例における各種データの状態を示し
た図である。

【図１９】第２実施例で想定したアプリケーション・プ
ログラムの仕様に沿った動作状況を示す入出力関連図で
ある。

【図２０】第１実施例で想定したアプリケーション・プ
ログラムの不具合による動作状況を示す入出力関連図で
ある。

【図２１】第２実施例における各種データの状態を示し
た図である。

【図２２】第２実施例における各種データの状態を示し
た図である。

【図２３】第２実施例における各種データの状態を示し
た図である。

【図２４】第２実施例における各種データの状態を示し
た図である。

【図２５】第２実施例における各種データの状態を示し
た図である。

【図２６】第２実施例における各種データの状態を示し
た図である。

【図２７】第３実施形態におけるハードウェア資源の構
成を示すブロック図である。

【図２８】第３実施形態におけるアプリケーションプロ
グラム開発システムの全体構成を示すブロック図であ
る。

【図２９】第３実施形態に係るプログラミング装置３２
のＧＵＩの画面構成を示す説明図である。

【図３０】第３実施形態に係るオブジェクト表示ペイン
の画面構成を示す説明図である。

【図３１】第３実施形態において、開発装置を利用しア
プリケーションシステムを開発する流れを示すフロー図
である。

【図３２】第３実施形態において、プログラミング装置
３２を利用し、システムコールを発行した時の、開発装
置の処理の流れを示すフロー図である。

【図３３】第３実施形態において、システムコールを発
行する場合の画面操作を示す説明図である。

【図３４】第３実施形態において、システムコール発行
位置チェックの流れを示すフロー図である。

【図３５】第３実施形態において、システムコール操作
対象位置チェックの流れを示すフロー図である。

【図３６】第３実施形態における実行状態ナビゲートラ
インの説明図である。

【図３７】第３実施形態におけるタスク部プログラミン
グ作業ペインとハンドラ部プログラミング作業ペインの
画面操作を示す説明図である。

【図３８】第３実施形態における割り込み発生イベント
をプログラミング中に仮想定義する際の画面操作を示す
説明図である。

【図３９】第３実施形態における割り込み発生イベント
発行時の流れを示すフロー図である。

【図４０】第３実施形態における割り込み発生イベント
定義時のアプリケーションプログラムの処理操作を示す
説明図である。

【図４１】第３実施形態において、時間経過をイベント
とし、プログラミング中に仮想定義する操作を示す説明
図である。

【図４２】従来のデバッガの構成を示した概略図であ
る。

【図４３】従来のデバッガが出力する実行履歴情報の構
成を示した概略図である。

【図４４】従来の実行履歴情報の構成とデータの一例を
示したイメージ図である。

【符号の説明】

１....ユーザーインタフェース部 ２....要求解析部 ３....タスク動作判定部 ４....実行履歴ファイル ５....ユーザー ６....システムコール対応テーブル １１....実行履歴情報 １２....入力データ １３....比較データ １４....検証データ １５....判定結果データ１ １６....判定結果データ２ １７....不具合質問用データ １８....プログラム １０１....ＯＳ １０２....デバッガ ５１…中央処理装置 ５２…ＲＡＭ ５３…ＲＯＭ ５４…通信装置 ５５…補助記憶装置 ５６…表示装置 ５７…入力装置 ５８…バス ５９…出力装置 ３１…環境定義部 ３２…プログラミング部 ４０…テンプレートファイル生成部 ４５…チェック部 ４６…実行オブジェクト生成部 ４８…表示情報生成部

───────────────────────────────────────────────────── フロントページの続き (72)発明者 山内 信之 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝マイクロエレクトロニクスセン ター内 (72)発明者 松本 奈津美 神奈川県川崎市幸区堀川町580番地 東芝 エルエスアイシステムサポート株式会社内 Ｆターム(参考） 5B042 GA23 GB05 HH01 HH30

Claims (20)

【特許請求の範囲】
1. 【請求項１】 プログラムの実行履歴情報をもとに、該
   プログラムの動作状況を時系列にユーザーに対して表示
   し、表示された動作状況の中でユーザーが指定する不具
   合の箇所を受付けるユーザーインタフェース手段と、 前記ユーザーインタフェース手段によってユーザーから
   指定された不具合の箇所と該プログラムの動作状況から
   不具合要因を解析し、この不具合要因を解決するための
   解決策を特定する動作解析手段とを有し、 前記動作解析手段は、前記解決策を反映させた動作状況
   を再作成し、 前記ユーザーインタフェース手段は、前記不具合要因と
   前記解決策と再作成した動作状況とをユーザーに表示す
   ることを特徴とする情報処理装置。
2. 【請求項２】 前記動作解析手段において、前記解決策
   を反映させる箇所を特定することができない場合に、 更に、ユーザーに該解決策を反映させる箇所の指定を促
   し、 前記動作解析手段は、このユーザーにより指定された箇
   所に該解決策を反映させた動作状況を再作成し、 前記ユーザーインタフェース手段は、前記不具合要因と
   解決策と再作成した動作状況とをユーザーに表示するこ
   とを特徴とする請求項１記載の情報処理装置。
3. 【請求項３】 前記情報処理装置は、前記解決策を特定
   するためのプログラム機能対応情報を有することを特徴
   とする請求項１記載の情報処理装置。
4. 【請求項４】 前記ユーザーインタフェース手段は、ユ
   ーザーが不具合の箇所を座標位置により指定すること
   で、該指定箇所を一意に認識することを特徴とする請求
   項１記載の情報処理装置。
5. 【請求項５】 前記情報処理装置は、更に、 前記解決策と前記実行履歴情報とをもとに、本来の仕様
   を満たすプログラムのスケルトンを自動生成することを
   特徴とする請求項１記載の情報処理装置。
6. 【請求項６】 プログラムの実行履歴情報をもとに、該
   プログラムの動作状況を時系列にユーザーに表示するス
   テップと、 ユーザーから指定された不具合の箇所と該プログラムの
   動作状況から不具合要因を解析し、この不具合要因を解
   決するための解決策を特定するステップと、 前記解決策を反映させた動作状況を再作成するステップ
   と、 前記不具合要因と前記解決策と再作成した動作状況とを
   ユーザーに表示するステップとをコンピュータに実現さ
   せることを特徴とする不具合解析プログラムを格納した
   コンピュータ読み取り可能な記憶媒体。
7. 【請求項７】 請求項６に記載の不具合解析プログラム
   を格納したコンピュータ読み取り可能な記憶媒体は、さ
   らに、 前記解決策を反映させる箇所を特定することができない
   場合に、ユーザーに該解決策を反映させる箇所の指定を
   促すステップと、 この指定された箇所に該解決策を反映させた動作状況を
   再作成するステップと、 前記不具合要因と前記解決策と再作成した動作状況とを
   ユーザーに表示するステップとをコンピュータに実現さ
   せることを特徴とする不具合解析プログラムを格納した
   コンピュータ読み取り可能な記憶媒体。
8. 【請求項８】 請求項６記載の不具合解析プログラムを
   格納したコンピュータ読み取り可能な記憶媒体は、 プログラム機能対応情報テーブルを用いて前記解決策を
   特定する機能をコンピュータに実現させることを特徴と
   する不具合解析プログラムを格納したコンピュータ読み
   取り可能な記憶媒体。
9. 【請求項９】 請求項６記載の不具合解析プログラムを
   格納したコンピュータ読み取り可能な記憶媒体は、さら
   に、 前記解決策と前記実行履歴情報とをもとに、本来の仕様
   を満たすプログラムのスケルトンを自動生成するステッ
   プをコンピュータに実現させることを特徴とする不具合
   解析プログラムを格納したコンピュータ読み取り可能な
   記憶媒体。
10. 【請求項１０】 プログラムの実行履歴情報をもとに、
    該プログラムの動作状況を時系列にユーザーに表示する
    ステップと、 ユーザーから指定された不具合の箇所と該プログラムの
    動作状況から不具合要因を解析し、この不具合要因を解
    決するための解決策を特定するステップと、 前記解決策を反映させた動作状況を再作成するステップ
    と、 前記不具合要因と前記解決策と再作成した動作状況とを
    ユーザーに表示するステップとを含むことを特徴とする
    不具合解析方法。
11. 【請求項１１】 請求項１０記載の不具合解析方法は、
    さらに、 前記解決策を反映させる箇所を特定することができない
    場合に、ユーザーに該解決策を反映させる箇所の指定を
    促すステップと、 この指定された箇所に該解決策を反映させた動作状況を
    再作成するステップと、 前記不具合要因と前記解決策と再作成した動作状況とを
    ユーザーに表示するステップとを含むことを特徴とする
    不具合解析方法。
12. 【請求項１２】 請求項１０記載の不具合解析方法は、
    プログラム機能対応情報テーブルを用いて前記解決策を
    特定することを特徴とする不具合解析方法。
13. 【請求項１３】 請求項１０記載の不具合解析方法は、
    更に、 前記解決策と前記実行履歴情報とをもとに、本来の仕様
    を満たすプログラムのスケルトンを自動生成するステッ
    プを含むことを特徴とする不具合解析方法。
14. 【請求項１４】 ハードウェア資源上で実行されるアプ
    リケーションプログラムの開発に用いられる開発支援シ
    ステムにおいて、 前記ハードウェア資源、およびソフトウェアを含む実行
    環境での実行時におけるシステム環境と、該実行環境の
    動作規則を定義する環境定義部と、 環境定義に基づいて前記実行環境におけるアプリケーシ
    ョンプログラムの仮想実行状態を検証するチェック部
    と、 前記仮想実行状態を可視的に表示するための表示情報を
    作成する表示情報作成部とを有することを特徴とするア
    プリケーションプログラム開発支援システム。
15. 【請求項１５】 前記表示情報を表示させる表示装置
    と、 前記表示装置の表示画面上に形成され、可視的に表示さ
    れた前記仮想実行状態を変化させる操作を該表示画面上
    で操作するインタフェース部とを有することを特徴とす
    る請求項１４に記載のアプリケーションプログラム開発
    支援システム。
16. 【請求項１６】 前記インタフェース部は、 前記仮想実行状態における任意のプログラム実行段階
    で、前記実行環境からシステムコールを発行させる機能
    と、 前記仮想実行状態における任意の実行環境の要素に対し
    て、前記実行環境資源からのシステムコールを発行させ
    る機能とにより該仮想実行状態を変化させるものである
    ことを特徴とする請求項１５に記載のアプリケーション
    プログラム開発支援システム。
17. 【請求項１７】 前記インタフェース部は、 前記仮想実行状態における実行環境上で操作される任意
    のオブジェクトに対して、前記実行環境からのシステム
    コールを発行させることにより該仮想実行状態を変化さ
    せるものであることを特徴とする請求項１５に記載のア
    プリケーションプログラム開発支援システム。
18. 【請求項１８】 前記インタフェース部は、 前記仮想実行状態における任意のプログラム実行段階
    で、前記実行環境上で割り込み起動される他のプログラ
    ムによるイベントを発行させることにより該仮想実行状
    態を変化させるものであることを特徴とする請求項１５
    に記載のアプリケーションプログラム開発支援システ
    ム。
19. 【請求項１９】 前記インタフェース部は、 前記仮想実行状態における任意のプログラム実行段階
    で、前記実行環境上で割り込み起動される他のプログラ
    ムによるイベントを発行させる機能と、当該他のプログ
    ラムの実行に要する時間を任意の長さに設定する機能と
    により該仮想実行状態を変化させるものであることを特
    徴とする請求項１５に記載のアプリケーションプログラ
    ム開発支援システム。
20. 【請求項２０】 前記アプリケーションプログラムを前
    記実行環境源上で実行可能な形態で出力する実行オブジ
    ェクト生成部を有することを特徴とする請求項１４記載
    のアプリケーションプログラム開発支援システム。