JP2009251762A - デバッガ装置、デバッグ方法およびプログラム - Google Patents

Abstract

【課題】デバッグ対象プログラム２４における動作不具合を発生する条件を効率よくみつけることを目的とする。
【解決手段】デバッグ対象プログラム２４と、このデバッグ対象プログラム２４を制御する制御プログラム２５とを合成させた合成後プログラム２６をコンパイルしたプロセスを実行する際に、前記制御プログラム２５に係る時点に到達したら、前記プロセスの実行を一次的に停止し、実行系列解釈部１１４が、モデル検査部（モデル検査プログラム）などによって出力された実行系列２３の１行を読込み、読み込んだ１行に記述されている命令に関する実行を前記プロセスに許可し、この許可を受けたプロセスが実行を再開することを特徴とする。
【選択図】図２

Description

本発明は、デバッガ装置、デバッグ方法およびプログラムの技術に関する。

プログラムの動作に不具合（プログラム作成者の意図と異なる動作）が発生した場合、動作不具合が再度発生しないようにプログラムの修正を行う。プログラムが動作不具合を生じる原因となるプログラム上の間違いをバグ、バグを修正し動作不具合が発生しないようにすることをデバッグと呼ぶ。デバッグでは、動作不具合の発生する条件を明らかにしたのち、同条件の下で動作不具合が発生しないようにプログラムソースを修正する。そして、動作不具合の発生する条件を明らかにするため、動作不具合が発生する状況に至るプログラムの実行過程を再現することが行われる。

デバッグには、デバッガと呼ばれるプログラム実行環境を用いることが一般的である。デバッガは、プログラムソースの行単位や、コンピュータの解釈する命令単位などのプログラム実行要素単位でプログラム実行を制御し、デバッグ対象プログラムを実行したり一時停止したりすることができるツールである。また、一般的なデバッガでは、プログラムソース上の特定の位置を予めブレークポイントとして設定し、プログラム実行がブレークポイントに至った時にプログラム実行を一時停止することができる。

さらに、ソフトウェアの動作は、ソフトウェアの実行開始時または実行中にソフトウェアに与える外部入力によって変化するが、同じ外部入力であっても同じ動作をするとは限らない。プログラムへ入力が与えられるタイミングでのプログラムの状態により動作が異なる。特に、複数のプロセスやタスクやスレッドと呼ばれる複数の実行単位からなり，それらの実行単位が並行して動作するソフトウェアにおいては、実行単位間の実行順序や実行タイミングなどのソフトウェアの実行過程の違いにより、同じ外部入力であっても動作結果が異なる場合がある。そのため、動作不具合が発生したプログラムに動作不具合発生時と同じ入力を与えて再度プログラムを実行しても、動作不具合が発生しないことがある。動作不具合が発生する条件を明らかにするには、プログラムへの入力内容と共に、時系列におけるプログラムの実行過程と実行過程のどのタイミングで入力がなされたかを知る必要がある。

また、従来のデバッガを用いたデバッグでは、並行して動作する複数のプログラム群の実行を同期して制御することは難しく、複数プログラム間の実行順序に起因して発生する動作不具合の発生条件を見つけることが難しい。

プログラムの実行過程を網羅的かつ自動的に分析する技術として、モデル検査技術がある。モデル検査技術は、あらかじめプログラムの動作仕様情報を専用言語で記述し、これとは別に数学的な記法を用いてプログラムが満たすべき性質情報を記述し、該プログラム動作仕様情報が、該性質情報を満たすかどうかを数学的に検査する技術である。モデル検査を実行するプログラムを、モデル検査プログラムと呼ぶことにする。代表的なモデル検査技術を実装した検査装置して、ＳＰＩＮ（例えば、非特許文献１参照）やＳＭＶ（Symbolic Medel Checker）やＵＰＰＡＡＬなどが存在する。

モデル検査プログラムは、プログラム動作仕様情報が性質情報を満たさない状態に至ることがある場合、その性質情報を満たさない状態に至るプログラムの動作過程を出力する。プログラム動作仕様情報に問題があり動作不具合が発生する場合には、動作不具合の論理的否定である望ましい動作を性質情報に記述し、モデル検査プログラムを用いて検査することで、動作不具合が発生する内部実行系列を得ることができる。
Ｇ．Ｊ． Ｈａｌｚｍａｎｎ著 「Ｔｈｅ ＳＰＩＮ ｍｏｄｅｌ ｃｈｅｃｋｅｒ： Ｐｒｉｍｅｒ ａｎｄ ｒｅｆｅｒｅｎｃｅ ｍａｎｕａｌ」 Ａｄｄｉｓｏｎ Ｗｅｓｌｅｙ， ２００４年

一般的なデバッガにおいてデバッグを行う者は、プログラムが動作不具合を発生する条件を想像しながらプログラムへの入力を行ったり、プログラムを一時停止時させて、プログラムの内部状態を参照したりすることにより、試行錯誤をしてプログラムが動作不具合を発生する条件を探索する。このような試行錯誤によるデバッグでは、動作不具合の発生条件を見つける効率が悪く、条件が見つからない場合もある。

また、モデル検査プログラムでは、デバッグ対象プログラムの記述に用いられるプログラミング言語とは異なる専用言語で記述した動作仕様情報を用いる。そのため、モデル検査プログラムを用いて、動作仕様情報について動作不具合が発生する実行過程を見つけたのち、デバッグ対象プログラムが同実行過程により不具合を生じることを用いて確認する必要がある。しかし、実行過程は動作仕様情報の実行に関するものであり、デバッグ対象プログラムの実行との対応はデバッグ実行者によって判断される必要がある。また、前記したように、従来のデバッガを用いて実行過程を正確に実行することは困難である。

このような背景に鑑みて本発明がなされたのであり、本発明は、デバッグ対象プログラムにおける動作不具合が発生する条件を効率よくみつけることを目的とする。

前記課題を解決するため、本発明は、デバッグ対象のプログラムを実行するプロセス実行部を備え、記憶部に格納されているプログラムの実行系列に従って、前記プロセス実行部において、実行されているデバッグ対象のプログラムの実行を制御することを特徴とする。

本発明によれば、デバッグ対象プログラムにおける動作不具合が発生する条件を効率よくみつけることができる。

次に、本発明を実施するための最良の形態（「実施形態」という）について、適宜図面を参照しながら詳細に説明する。なお、本実施形態では、コンパイル前のプログラムを、「プログラム」と記載し、コンパイルした後、実際に実行するプログラムを「プロセス」と記載することとする。

図１は、本実施形態に係るプログラム実行制御装置の構成例を示す図である。
プログラム実行制御装置１（デバッガ装置）は、デバッガ実行部１１と、入力部１３と、モデル検査部１２と、記憶部１４とを有してなる。
モデル検査部１２は、動作仕様情報２１および性質情報２２を入力とし、動作仕様情報２１が性質情報２２を満たすか否かを検査する。動作仕様情報２１が、性質情報２２を満たさないことがある場合には、動作仕様情報２１が性質情報２２を満たさない状況にいたる実行系列２３を出力して、記憶部１４に格納する。この結果、実行系列２３には、プロセスの実行手順の系列が記述されることになる。

モデル検査部１２として、モデル検査プログラムを用いることができる。代表的なモデル検査プログラムとして、ＳＰＩＮがある。本実施形態では、モデル検査部１２としてＳＰＩＮを用いる例を示すが、モデル検査プログラムとしてＳＰＩＮに限定するものではなく、ＳＭＶやＵＰＰＡＡＬもしくは他のモデル検査プログラムを用いてもよい。また、ＳＰＩＮを用いたモデル検査では、アルゴリズムと手順である動作仕様情報２１をＰｒｏｍｅｌａと呼ぶ専用言語を用いて記述し、性質情報２２をＬｉｎｅａｒ Ｔｅｍｐｏｒａｌ Ｌｏｇｉｃと呼ぶ様相論理に基づく論理式で記述する。モデル検査部１２は、動作仕様情報２１のすべての実行状態を網羅的に探索し、性質情報２２を満たすかどうかを検査する。動作仕様情報２１が性質情報２２を満たさない場合には、モデル検査部１２は、動作仕様情報２１が性質情報２２を満たさない状態に至るまでの実行系列２３を出力し、記憶部１４に格納する。実行系列２３は、図３を参照して後記するが、動作仕様情報２１の行単位の実行順序と通信順序を含む。デバッガ実行部１１は、実行系列２３を入力とし、入力部１３から入力されたデバッグの対象となるプログラム（デバッグ対象プログラム２４）の実行を制御する。

図２は、デバッガ実行部の構成例を示す図である。
デバッガ実行部１１は、プログラム合成部１１１と、コンパイラ１１２と、プロセス実行部１１３と、実行系列解釈部１１４と、出力部１１５とを有してなる。
プログラム合成部１１１は、前記したデバッグ対象プログラム２４と、入力部１３から入力された制御プログラム２５とを合成し、合成後プログラム２６を出力する機能を有する。デバッグ対象プログラム２４と、制御プログラム２５の合成は、両者のソースプログラムを連結することによって行われる。このようなプログラム同士の合成は、ＡｓｐｅｃｔＪなどのアスペクト指向のプログラム技術において標準的な機能である。

ここで、制御プログラム２５とは、デバッグ対象プログラム２４（デバッグ対象プロセス）の実行を制御することを目的とするプログラムである。制御プログラム２５による制御プロセスがデバッグ対象プロセスの実行を制御するために、プログラム合成部１１１は、制御プログラム２５とデバッグ対象プログラム２４を合成し、合成後プログラム２６を生成する。
プロセス実行部１１３は、コンパイラ１１２によってコンパイルされたプロセスを逐次解釈しながら実行するインタプリタ方式、合成後プログラム２６をあらかじめＣＰＵ命令に変換してＣＰＵ（Central Processing Unit）が実行するコンパイラ方式、もしくは他の実行方式であってよい。
実行系列解釈部１１４は、実行系列２３を読込み、実行系列２３に定義された順にデバッグ対象プロセスを実行するよう、合成後プログラム２６（プロセス）に含まれる制御プロセスへ指示を与える。
出力部１１５は、実行系列解釈部１１４による出力結果を表示したり、印刷したりする機能を有する。

なお、デバッグ対象プログラム２４（デバッグ対象プロセス）は、単一プログラムである必要はなく、並行して動作する複数のプログラム群であってよい。これに対応し、動作仕様情報２１（図１参照）も並行して動作する複数の仕様群であってよい。

次に、図１を参照しつつ図３に沿って実行系列について説明する。
図３は、実行系列の例を示す図である。
本実施形態において、合成後プログラム２６をコンパイルしたプロセスは、並行して動作し相互に通信が可能な３つのプロセスであるプロセスＡ、プロセスＢおよびプロセスＣからなるものとする。
実行系列２３の各行は、制御すべきデバッグ対象プログラム２４の実行単位を意味する。実行単位は、デバッグ対象プログラム２４の特定の実行行に対応する。列３０１は実行単位の連番を示すものであり、省略してもよい。列３０２は、対象となるプロセスを区別するための情報である。列３０３は、実行単位の実行内容を示す。例えば、行３０４は、該当する列３０２が示す「プロセスＡ」が、該当する列３０３に示す「オブジェクトｏｂｊ＿ａ生成」を実行することを示す。なお，行３０４の列３０３に記載の「（Ａ−２）」は、「オブジェクトｏｂｊ＿ａ生成」という実行単位を示す識別子であり、実行単位を識別できれば図３のような「（Ａ−２）」に限られるものではない。

また、行３０５ではプロセスＢからプロセスＡへのデータ送信、行３０６ではプロセスＡのデータ受信、行３０７ではプロセスＣからプロセスＡへのデータ送信、行３０８はプロセスＡのデータ受信が順に行われることを示す。

なお、図３に示す例は、実行系列２３における情報の例を示すものであり、図３に示すデータフォーマットおよび内容を限定するものではなく、類似の意味を有する実行系列２３であればよい。
また、図３に示す例では、日本語を用いた表形式により実行系列２３を定義しているが、計算機が処理可能な任意のデータ形式でよい。

図４は、本実施形態におけるプロセス実行部と、実行系列解釈部との関係を示す図である。
プロセスＡ〜プロセスＣのそれぞれには、プロセスのソースプログラムをコンパイルしたデバッグ対象プロセスＡ〜デバッグ対象プロセスＣが含まれ、実行系列２３に示される実行単位に対応した複数の制御プログラム２５をコンパイルした制御プロセスを含んでいる。実行系列解釈部１１４は、実行系列２３を入力とし、この実行系列２３の各行を順に読込み、各行の実行内容に対応する各プロセス中の制御プロセスに実行を指示する。実行系列解釈部１１４から制御プロセスへの指示は、プロセス間通信方式、共有データ方式など、プログラム間で通信可能な任意の方法で行われてもよい。

次に、図２を参照しつつ、図５に沿って実行系列解釈部１１４における処理を説明する。
図５は、実行系列解釈部における処理の流れを示すフローチャートである。
まず、実行系列解釈部１１４は、実行系列２３の１行を読み込む（Ｓ１０１）。
次に、実行系列解釈部１１４は、ステップＳ１０１で読み込んだ実行系列２３の実行内容に対応する制御プロセスを特定する（Ｓ１０２）。
そして、実行系列解釈部１１４は、ステップＳ１０２で特定した対象プロセスに対し、処理の実行を許可する（Ｓ１０３）。
処理の実行を指示された制御プロセスは、制御対象となっているデバッグ対象プロセスの処理を実行し、実行系列解釈部１１４へ実行を行う旨を応答（実行の応答）する。そして、実行系列解釈部１１４は、制御プロセスから実行の応答を受信する（Ｓ１０４）。
そして、実行系列解釈部１１４は、実行系列２３の全行を読み込んだか否かを判定する（Ｓ１０５）。
ステップＳ１０５の結果、実行系列２３の全行を読み込んでいない場合（Ｓ１０５→Ｎｏ）、実行系列解釈部１１４は、ステップＳ１０１へ処理を戻し、実行系列２３の次の１行を読み込む。
ステップＳ１０５の結果、実行系列２３の全行を読み込んでいる場合（Ｓ１０５→Ｙｅｓ）、処理を終了する。

次に、図２を参照しつつ、図６に沿ってプロセス実行部１１３における処理を説明する。
図６は、プロセス実行部における処理の流れを示す図である。なお、図６における処理は、プロセス実行部１１３においてプロセス毎に並行して行われる処理である。
プロセス実行部１１３は、プロセスを実行し（Ｓ２０１）、プロセスに含まれる制御プロセスに到達したか否かを判定する（Ｓ２０２）。
ステップＳ２０２の結果、制御プロセスに到達していない場合（Ｓ２０２→Ｎｏ）、ステップＳ２０１へ処理を戻し、引き続きプロセス実行を継続する。
ステップＳ２０２の結果、制御プロセスに到達した場合（Ｓ２０２→Ｙｅｓ）、プロセス実行部１１３は、プロセスの実行を一時停止し、実行系列解釈部１１４からの実行指示を待つ（Ｓ２０３）。
そして、プロセス実行部１１３は、実行系列解釈部１１４からの実行指示を受ける（Ｓ２０４）と、実行系列解釈部１１４に該当するプロセスを実行した旨の応答を送り（Ｓ２０５）、ステップＳ２０１へ処理を戻す。

図７は、各プロセスと実行系列解釈部との情報の授受を示すシーケンス図である。
ここでは、実行系列２３として、図３の行３０５から行３０７が入力された場合を示す。
デバッグ対象プロセスとしてデバッグ対象プロセスＡ（プロセスＡにおけるデバッグ対象プログラム２４部分）、デバッグ対象プロセスＢ（プロセスＢにおけるデバッグ対象プログラム２４部分）、デバッグ対象プロセスＣ（プロセスＡにおけるデバッグ対象プログラム２４部分）を考える。また、プロセスにおける制御プログラム２５部分を示す制御プロセスとして、図３に対応し実行単位「Ａ−２０」に対応する制御プロセス「Ａ−２０」、実行単位「Ｂ−９」に対応する制御プロセス「Ｂ−９」、および実行単位「Ｃ−１２」に対応する制御プロセス「Ｃ−１２」を考える。

制御プロセス「Ａ−２０」は、デバッグ対象プロセスＡが実行要素「Ａ−２０」を実行する直前に埋め込まれ、制御プロセス「Ｂ−９」は、デバッグ対象プロセスＢが実行要素「Ｂ−９」を実行する直前に埋め込まれる。制御プロセス「Ｃ−１２」は、デバッグ対象プロセスＣが実行要素「Ｃ−１２」を実行する直前に埋め込まれる。
まず、デバッグ対象プロセスＣが実行単位「Ｃ−１２」実行の直前に至ったとすると（Ｓ３１１）、制御プロセス「Ｃ−１２」に実行が移る（Ｓ３１２）。
そして、ステップＳ３１３において、制御プロセス「Ｃ−１２」は、実行系列解釈部１１４からの実行指示を待つ。

次に、デバッグ対象プロセスＢが実行単位「Ｂ−９」実行の直前に至ったとすると（Ｓ３１４）、デバッグ対象プロセスＢから制御プロセス「Ｂ−９」に実行が移る（Ｓ３１５）。そして、ステップＳ３１６において、制御プロセス「Ｂ−９」は、実行系列解釈部１１４からの実行指示を待つ。
ステップＳ３１７において、実行系列解釈部１１４が、実行系列２３の行３０５（図３）を読み込むと（Ｓ３１７）、実行系列解釈部１１４は、行３０５に対応する制御プロセス「Ｂ−９」に対して実行を指示する（Ｓ３１８）。実行指示を受けた制御プロセス「Ｂ−９」は、実行系列解釈部１１４へ応答を返し（Ｓ３１９）、処理を終える。
処理は、デバッグ対象プロセスＢに戻り（Ｓ３２０）、ステップＳ３２１においてデバッグ対象プロセスＢにおける実行単位「Ｂ−９」を実行する（Ｓ３２１）。
以下、デバッグ対象プロセスＡの実行単位「Ａ−２０」、デバッグ対象プロセスＣの実行単位「Ｃ−１２」、デバッグ対象プロセスＡの実行単位「Ａ−２０」を実行する（それぞれ、図３における行３０６，３０７，３０８に相当）

ここで、デバッグ対象プロセスＣの実行状態を見ると、ステップＳ３１１において実行単位「Ｃ−１２」を実行可能であり、本実施形態による実行制御を行わなければ、即座にデバッグ対象プロセスＣは、実行単位「Ｃ−１２」を実行することとなるので、デバッグ対象プロセスＡ〜Ｃの実行順序は、図７と異なる実行順序となる。本実施形態によれば、処理が、デバッグ対象プロセスＣから制御プロセス「Ｃ−１２」に移り、実行系列解釈部１１４が実行単位「Ｃ−１２」に対応する実行系列２３の行３０７（図３）を読み込むまで、デバッグ対象プロセスＣは、処理を一時停止し、ステップＳ３３０において実行単位「Ｃ−１２」を実行する。このように、制御プログラム２５（制御プロセス）と実行系列解釈部１１４によりデバッグ対象プログラム２４（デバッグ対処プロセス）の実行を一時停止し、実行系列２３の順に実行を再開することで、実行系列２３に定義された順にデバッグ対象プロセスの実行を制御することができる。つまり、本実施形態によれば、モデル検査プログラム（モデル検査部１２）が出力する実行系列２３に従って、デバッグ対象プロセスを自動的に実行することで、デバッグ対象プログラム２４（デバッグ対象プロセス）が動作不具合を発生する条件を効率よくみつけることができる。

制御プログラム２５をデバッグ対象プログラム２４に埋め込む方法として、アスペクト指向プログラム技術を用いることができる。アスペクト指向プログラム技術では、本実施形態でのデバッグ対象プログラム２４に相当する実プログラムと、それと独立したアスペクトと呼ぶプログラム断片を定義することができる。アスペクトでは、実プログラム上の位置の位置と、その位置に埋め込むプログラム断片を定義する。アスペクト指向プログラム言語の処理系は、アスペクトを解釈し、アスペクトに定義された位置にプログラム断片を埋め込む。

このようなアスペクト指向プログラム技術の１つにＡｓｐｅｃｔＪがある。ＡｓｐｅｃｔＪは、プログラム言語Ｊａｖａ（登録商標）に対応したアスペクト指向プログラム言語および処理系である。ＡｓｐｅｃｔＪでは、実プログラム上の位置をｐｏｉｎｔｃｕｔ演算子で定義し、これをポイントカットと呼ぶ。プログラム断片をポイントカットの直前に埋め込むには、ｂｅｆｏｒｅ演算子を用いてプログラム断片を定義する。

図８および図９を参照して、アスペクト指向プログラム技術による、本実施形態における制御プログラム２５の例を示す。
図８は、デバッグ対象プログラムのソースコードの一部を示す例である。
例示するデバッグ対象プログラム２４は、図４および図７におけるデバッグ対処プロセスＢのソースプログラム（デバッグ対象プログラムＢ）である。
図８では、プログラムＢを構成するクラスとしてｐｒｏｇｒａｍ＿Ｂクラス（行８０１）が定義されており、他のプログラムにメッセージを送るｓｅｎｄ＿ｍｅｓｓａｇｅメソッド（行８０３）が定義されているものとする。行８０３におけるｓｅｎｄ＿ｍｅｓｓａｇｅメソッドは、第１引数に送信先、第２引数に送信する値を持つものとする。行８０２は、プログラムＡに対し値ａを送ることを意味する。すなわち、行８０２は、図３における行３０５の「Ｂ−９」に対応する。

図９は、図８を前提とした「Ｂ−９」に対応する制御プログラムのソースコードの例を示す。
行９０１は、Ｃｏｎｔｒｏｌ＿ｐｒｏｇｒａｍ＿Ｂ−９というアスペクトを定義することを宣言している。行９０２は、「．ｓｅｎｄ＿ｍｅｓｓａｇｅ（” Ａ”， ” ａ）”」という文字列を持つ実行行を、「Ｂ−９」という名を持つポイントカットとして定義している。なお、「＊」は任意の文字列を意味する。行９０３は、「ｂｅｆｏｒｅ」演算子を用いて、ポイントカットＢ−９を実行する直前に以下のプログラムを実行することを定義している。行９０４は、実行系列解釈部１１４からの実行指示を待ち受けする「ｗａｉｔｉｎｇ＿ｆｏｒ＿ｅｘｅｃｕｔｉｏｎ」の実行、行９０５は、実行系列解釈部１１４への実行応答を送る「ｒｅｓｐｏｎｄ＿ｆｏｒ＿ｅｘｅｃｕｔｉｏｎ」の実行を定義している。これらは別途定義されているものとする。

ＡｓｐｅｃｔＪの処理系を用いて、図９に示すプログラムを、図８に示すプログラムに埋め込むことで、図８の行８０２を実行する直前に、図９の行９０３以降で定義した行９０４が実行される（これは、図７におけるステップＳ３１６にあたる）。これにより、デバッグ対象プログラムＢ（デバッグ対象プロセスＢ）は、実行系列解釈部１１４からの実行指示を待つ。そして、図７のステップＳ３１８で、制御プロセス「Ｂ−９」が、実行系列解釈部１１４からの実行指示を受ける（図９の行９０４に相当）と、図７のステップＳ３１９で実行系列解釈部１１４に応答を返す（図９の行９０５に相当）。この後、デバッグ対象プログラムＢ（デバッグ対象プロセスＢ）は、実行単位「Ｂ−９」に相当する行８０２（図８）の実行を行う。

このように、アスペクト指向プログラム技術により、モデル検査部１２が出力した実行系列２３に従い、プロセス実行部１１３はデバッグ対象プログラム２４（デバッグ対象プロセス）の実行を制御できる。さらに、本実施形態によれば、プログラム実行部に特別な機能を有することなしに、デバッグ対象プログラム２４の実行を制御できる。なお、アスペクト指向プログラムを用いた例を示すため、ＡｓｐｅｃｔＪを用いたプログラムを示したが、本実施形態はＡｓｐｅｃｔＪの利用に限定されるものではなく、他のプログラム言語や処理系を用いてもよい。

図１０は、本実施形態に示すプログラム実行制御装置のハードウェア構成例を示す図である。
プログラム実行制御装置１は、ＣＰＵ１００１、ＲＡＭ（Random Access Memory）１００２、ＲＯＭ（Read Only memory）１００３、ＨＤ（Hard Disk）１００４を有してなる。これらの各装置１００１〜１００４は、バス１００５を介して互いに接続されている。
図１に示すモデル検査部１２およびデバッガ実行部１１は、ＲＯＭ１００３や、ＨＤ１００４に格納されたプログラムが、ＲＡＭ１００２に展開され、ＣＰＵ１００１によって実行されることによって具現化する。

本実施形態に係るプログラム実行制御装置の構成例を示す図である。 デバッガ実行部の構成例を示す図である。 実行系列の例を示す図である。 本実施形態におけるプロセス実行部と、実行系列解釈部との関係を示す図である。 実行系列解釈部における処理の流れを示すフローチャートである。 プロセス実行部における処理の流れを示す図である。 各プロセスと実行系列解釈部との情報の授受を示すシーケンス図である。 デバッグ対象プログラムのソースコードの一部を示す例である。 図８を前提とした「Ｂ−９」に対応する制御プログラムのソースコードの例である。 本実施形態に示すプログラム実行制御装置のハードウェア構成例を示す図である。

符号の説明

１ プログラム実行制御装置（デバッガ装置）
１１ デバッガ実行部
１２ モデル検査部
１３ 入力部
１４ 記憶部
２１ 動作仕様情報
２２ 性質情報
２３ 実行系列
２４ デバッグ対象プログラム
２５ 制御プログラム
２６ 合成後プログラム
１１１ プログラム合成部
１１２ コンパイラ
１１３ プロセス実行部
１１４ 実行系列解釈部
１１５ 出力部

Claims (6)

1. プログラムのデバッグを行うデバッガ装置であって、
   入力部から入力されたデバッグ対象のプログラムを実行するプロセス実行部と、
   記憶部に格納されているプログラムの実行系列を読み込み、前記実行系列に従って、前記プロセス実行部において実行されているデバッグ対象のプログラムの実行を制御する実行系列解釈部とを有することを特徴とするデバッガ装置。
2. 前記入力部から入力されたアルゴリズムと手順とが記述されている動作仕様情報と、前記動作仕様書に係る性質が記述されている性質情報とを用いて、前記実行系列を前記記憶部に記憶するモデル検査部をさらに有することを特徴とする請求項１に記載のデバッガ装置。
3. デバッグ対象のソースプログラムに、前記ソースプログラムの実行を制御する制御プログラムを合成して、前記デバッグ対象のプログラムを生成するプログラム合成部をさらに有することを特徴とする請求項１に記載のデバッガ装置。
4. 前記モデル検査部は、ＳＰＩＮ、ＳＭＶおよびＵＰＰＡＡＬのうち、いずれか１つのモデル検査プログラムであることを特徴とする請求項２に記載のデバッガ装置。
5. プログラムのデバッグを行うデバッガ装置におけるデバッグ方法であって、
   前記デバッガ装置は、
   デバッグ対象のプログラムを実行するプロセス実行部を備え、
   記憶部に格納されているプログラムの実行系列に従って、前記プロセス実行部において、実行されているデバッグ対象のプログラムの実行を制御することを特徴とするデバッグ方法。
6. 請求項５に記載のデバッグ方法を、コンピュータに実行させることを特徴とするプログラム。
   
   

Images