JPH05265802A

JPH05265802A - ソフトウェアデバッグ装置

Info

Publication number: JPH05265802A
Application number: JP4091577A
Authority: JP
Inventors: Yasuo Miwa; 泰生三輪
Original assignee: Shimadzu Corp
Current assignee: Shimadzu Corp
Priority date: 1992-03-18
Filing date: 1992-03-18
Publication date: 1993-10-15

Abstract

(57)【要約】【目的】プログラム仕様上でのデバッグを可能とし
た、ソフトウエアデバッグ装置を提供すること。【構成】環境設定部１では、プログラム仕様に基づ
き、テストデータを対話形式により作成し、データ管理
部２で保管する。テスト対象のプログラム仕様は、部品
データベース７中の部品を用いながら、実行イメージ８
に変換される。ユーザの実行指示により、実行制御部３
は、実行すべき関数の指示と、データ管理部２からのテ
ストデータを、実行イメージ８に引き渡し、実行結果を
受け取る。実行結果は、データ管理部２に保管され、要
求に応じて表示される。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ソフトウェアデバック
の支援装置に関するものである。

【０００２】

【従来の技術】従来のソフトウェア開発においては、プ
ログラムの仕様書を作成し、仕様書に基づいてプログラ
マがソースコードを作成し、コンパイラなどで実行イメ
ージのプログラムを作成している。このようなソフトウ
ェアの開発過程において、仕様書や、ソースコードの作
成時に誤りが発生するため、従来より誤りの修正、すな
わちデバッグが必要であり、そのためのツールも開発さ
れている。

【０００３】従来のデバッグ作業は、プログラマの作成
したソースコードに基づいて行なわれていた。そのた
め、デバッグの作業は、そのソースコードを理解できる
人が行なわなければならなかった。また、ソースコード
を１行１行追っていかねばならず効率が悪く、しかも、
不注意による見逃しが発生しやすいという問題がある。

【０００４】近年、ソフトウェアの生産性向上およびプ
ログラムエラーの低減などの観点から、プログラムの仕
様からソースコードおよび実行形式のイメージまでを自
動的に生成する研究が進み、実用化されつつある。ユー
ザは、プログラム仕様を一定の形式によってコンピュー
タ上で作成する。作成されたプログラム仕様は、変換手
段によってソースコードが自動生成され、コンパイラな
どによって実行イメージが作成され、実行される。これ
により、プログラミングの工程を省略でき、生産性が向
上するとともに、プログラミング時の誤りを防止でき
る。しかし、プログラム仕様などのエラーは依然として
残るため、プログラム仕様上でのデバッグが必要であ
る。従来は、プログラム仕様からソースコードが自動生
成されるシステムであっても、デバッグは依然としてソ
ースコード上で行なわれており、プログラム仕様上での
デバッグのためのツールもなかった。

【０００５】

【発明が解決しようとする課題】本発明は、プログラム
仕様上でのデバッグを可能とするデバッグ装置を提供す
ることを目的とするものである。

【０００６】

【課題を解決するための手段】本発明は、プログラム仕
様に対してテスト、デバッグを行なうソフトウェアデバ
ッグ装置において、プログラム仕様の入力、管理を行な
うプログラム仕様管理部と、テストデータの入力作成を
対話的に行なう環境設定部と、対話的な指示に基づき、
入力データの割当と、実行可能な状態に変換されたプロ
グラム仕様の実行を制御する実行制御部と、環境設定部
において作成されたテストデータ、および実行結果を記
憶し、管理するデータ管理部と、対話的なデータの表示
および指示を行なうユーザインタフェース部を有するこ
とを特徴とするものである。

【０００７】

【作用】本発明によれば、プログラムの仕様と、実際に
動作する実行イメージが対応付けられており、予め入力
されたテストデータを用いてプログラムを実行し、その
結果を得ることができるから、プログラムの仕様上での
デバッグを行なうことができる。また、テストデータの
入力作成、プログラム仕様の表示、修正、プログラムの
実行、実行結果の表示を対話的に行なえるから、効率の
良いデバッグを行なうことができる。

【０００８】

【実施例】図１は、本発明のソフトウェアデバッグ装置
の一実施例を示す概略図である。図中、１は環境設定
部、２はデータ管理部、３は実行制御部、４はユーザイ
ンタフェース部、５はプログラム仕様管理部、６はプロ
グラム仕様作成手段、７は部品データベース、８は実行
イメージである。

【０００９】環境設定部１は、テストの対象となるプロ
グラム仕様に必要なテストデータを、ユーザとの対話に
より作成する。データ管理部２は、環境設定部１におい
て作成されたテストデータおよび実行制御部３において
実行されたプログラムの実行結果を記憶し、管理する。
実行制御部３は、ユーザとの対話により、テストするプ
ログラムの選択実行、および、テストするプログラムに
与えるテストデータなどの入力データの割り当てを行な
う。ユーザインタフェース部４は、ユーザからの入力、
例えば、キーボードからの入力や、マウスによる位置情
報などを受け取り、環境設定部１や実行制御部３に入力
を伝え、また、環境設定部１や実行制御部３からの表示
情報や、データ管理部２内の実行結果を、ユーザからの
入力にしたがって表示装置、例えばＣＲＴなどに表示す
る。プログラム仕様管理部５は、入力されるテスト対象
のプログラム仕様を受け取り、管理する。これらによっ
て、この実施例におけるデバッグ装置を構成している。

【００１０】データ管理部２や、プログラム仕様管理部
５において管理されているデータ等は、例えば、磁気デ
ィスクやＲＡＭ上に記憶され、ユーザや、各部から呼び
出され、使用される。

【００１１】プログラム仕様作成手段６は、開発するソ
フトウェアのプログラム仕様を作成するための手段であ
る。部品データベース７には、以前に開発したプログラ
ムの部分（部品）を格納してある。実行イメージ８は、
プログラム仕様と部品とから生成された、実際に動作す
るプログラムである。

【００１２】図１で説明した実施例の動作を説明する。
開発されるソフトウェアのプログラム仕様は、プログラ
ム仕様作成手段６で作成される。作成されたプログラム
仕様のうち、テストの対象となるプログラム仕様は、プ
ログラム仕様管理部５に入力される。また、環境設定部
１では、入力されたプログラム仕様に基づき、テストを
行なう際のテストデータを、ユーザインタフェース４を
介したユーザとの対話により作成する。作成されたテス
トデータは、データ管理部２で保管される。

【００１３】一方、プログラム作成手段６で作成された
プログラム仕様は、部品データベース７中の部品を用い
て、図示しない変換手段により、プログラム仕様に対応
した実行イメージ８が作成される。この実行イメージ８
は独立したタスクとして動作する。

【００１４】ユーザインタフェース４を介してユーザか
らの実行指示が実行制御部３になされると、実行制御部
３はプロセス間通信などの手法によって、実行イメージ
８に対し、実行すべきプログラムモジュールを指示し、
またプログラムモジュールの実行に必要なテストデータ
をデータ管理部２から呼び出して、実行イメージ８に引
き渡す。実行イメージ８では、渡されたテストデータを
入力として、指示されたプログラムモジュールが実行さ
れ、実行結果を、やはりプロセス間通信などの手法によ
って、実行制御部３に送る。実行制御部３が受け取った
実行結果はデータ管理部２に保管され、ユーザインタフ
ェース４を介したユーザからの要求にしたがって、表示
される。

【００１５】実行イメージ８は独立したタスクとして動
作すると説明したが、本発明のデバッグ装置と一体とし
て構成されても良い。その場合は、実行イメージ８内の
プログラムモジュールの実行の指示およびデータの受け
渡しは、単なる関数呼び出しと、呼び出す際のパラメー
タの受け渡しで行なうことができる。しかし、実際の動
作環境における実行イメージのデバッグを行なうために
は、実行イメージ８は上述のように独立したタスクとし
て動作するようにした方がよい。

【００１６】上述の一実施例について、より具体的に説
明する。図２は、本実施例において用いるプログラム仕
様の説明図である。本実施例において用いているプログ
ラム仕様は、データフロー型のソフトウェア開発用であ
り、図２に図示されているように、図式によって視覚的
にプログラム仕様を記述でき、また制御構造を階層的に
表現できるものである。プログラム仕様は、処理内容を
表すプロセスとその間のデータの流れを表すデータフロ
ーダイアグラム、制御構造を表すプロセスフローダイア
グラム、および使用するデータの構造を定義するデータ
構造定義の３つの部分からなる。図２（Ａ）の上半分が
データフローダイアグラム、図２（Ａ）の下半分がプロ
セスフローダイアグラム、図２（Ｂ）がデータ構造定義
の具体例である。図中、ＩＰ１〜ＩＰ３は入力処理プロ
セス、ＭＰ１、ＭＰ２は変換処理プロセス、ＯＰ１は出
力処理プロセス、Ｄ１〜Ｄ５はデータのそれぞれが表示
されていることを示している。

【００１７】データフローダイアグラムには、各データ
の流れを図式により記述する。矢線がデータの流れを示
し、矢線の付近にデータ名が記述される。また、四角形
または角の丸い四角形が処理を行なうプロセスをしめ
し、矩形中にプロセス名が記述される。図２（Ａ）の例
では、入力処理プロセスＩＰ１とＩＰ２によって入力さ
れたデータＤ１およびＤ２が、変換処理プロセスＭＰ１
に入力され、処理が行なわれて、データＤ４が出力され
る。この出力されたデータＤ４と、入力処理プロセスＩ
Ｐ３により入力されたデータＤ３は、変換処理プロセス
ＭＰ２に入力されて処理が行なわれ、データＤ５が出力
される。出力されたデータＤ５は、出力処理プロセスＯ
Ｐ１が出力されることを示している。

【００１８】このデータフローダイアグラムでは、デー
タの流れが記述されるが、処理プロセスの順序、例えば
各入力処理プロセスの順序などは規定できない。そのた
め、プロセスフローダイアグラムによって、実際の処理
の順序などの制御構造を規定する。図２（Ａ）の例で
は、入力処理プロセスＩＰ１、入力データ処理プロセス
ＩＰ２、入力処理プロセスＩＰ３、変換処理プロセスＭ
Ｐ１、変換処理プロセスＭＰ２、出力処理プロセスＯＰ
１の順で処理が行なわれることが記述されている。

【００１９】データ構造定義には、データフローダイア
グラムにおいて流れが記述された、各データの構造や
型、配列の大きさ、とり得る値などを規定する。図２
（Ｂ）では、例えば「測定波形」というデータは、整数
型のデータであって、１２８個の配列であることが記述
されている。この「測定波形」というデータ名は、デー
タフローダイアグラムのデータの流れを示す矢線上に記
述されているデータ名と対応するものであり、例えば、
図２（Ａ）中の「Ｄ１」という表示部分などにに記載さ
れる。本実施例では、データ構造定義は、プログラム仕
様に一つだけ存在する。しかし、各データフローダイア
グラムやプロセスフローダイアグラムと同様に、各図面
毎に存在するように構成しても良い。

【００２０】上述のプログラム仕様の記述方法は、一つ
の記法を示したに過ぎず、ＨＩＰＯやＰＡＤなど、従来
の記法を用いたシステムとしても良い。

【００２１】また、図２（Ａ）は、図１のプログラム仕
様管理部５において管理している、テストすべきプログ
ラム仕様を、図１のユーザインタフェース４を介して表
示装置に表示したときの、表示装置上の一つのウインド
ウを示している。図２（Ｂ）に示されるウインドウも、
表示装置に表示される。表示装置上のウインドウは、そ
れぞれ並んで、または上下関係を持って重ねて表示され
る。重なったウインドウの上下関係の変更や、ウインド
ウの生成、消滅、大きさの変更、視野の変更などは通常
のウインドウシステムと同様である。また、図２（Ａ）
の左脇の欄と、上から２段目の欄は、ユーザが選択する
機能を表示しており、マウスなどのポインティングデバ
イスで選択される。点線で示されている各項目は、現在
の画面では、選択できない項目であることを示してい
る。以下の説明でユーザが機能を選択する場合は、点線
でない項目をマウスなどのポインティングデバイスなど
で指示するか、または対応するキーボード上のキーを押
下することによって行なわれる。

【００２２】図３は、プロセスの階層構造を示す概略図
である。図中、ＨＰ１、ＭＰ１、ＭＰ２、ＬＰ１〜ＬＰ
５はプロセスである。図示された各プロセスに対して、
それぞれデータフローダイアグラムおよびプロセスフロ
ーダイアグラムが記述される。これを図面と呼ぶことに
する。各図面の集合体、およびデータ構造定義により、
プログラム仕様が構成される。図３では、図面の存在す
るプロセスのみがツリー構造として示されている。

【００２３】上述したように、プログラム仕様は階層的
に表現される。プロセスＨＰ１の下位展開としてプロセ
スＭＰ１およびＭＰ２が存在する。すなわち、プロセス
ＨＰ１は、プロセスＭＰ１およびＭＰ２を用いて構成さ
れる。同様に、プロセスＭＰ１の下位には、プロセスＬ
Ｐ１およびプロセスＬＰ２が、プロセスＭＰ２の下位に
はプロセスＬＰ３ないしＬＰ５がそれぞれ展開されてい
る。例として、図２（Ａ）をプロセスＨＰ１の図面とす
る。同図に図示されているように、プロセスＭＰ１およ
びＭＰ２を用いて、データフローダイアグラムおよびプ
ロセスフローダイアグラムが記述されている。

【００２４】図４は、下位展開されたプロセスの図面の
概略図である。例えば、図４に示された図面を、図２
（Ａ）中のプロセスＭＰ１の図面と考えれば、プロセス
ＭＰ１はプロセスＬＰ１およびＬＰ２を用いていること
がわかる。このように、各プロセスが階層的に記述され
る。図４は、具体的には、データＤ２の値によって処理
を行なうプロセスを切り換えることを示し、プロセスＬ
Ｐ１またはプロセスＬＰ２のどちらかが実行され、実行
の際には、入力データとしてデータＤ１が入力され、出
力データとしてデータＤ４が出力されることを示してい
る。上述したプログラム仕様のうち、テストおよびデバ
ッグを行なうべき図面は、プログラム仕様管理部５に入
力される。

【００２５】テストを実行する前に、テストデータの作
成を、環境設定部１によって行なう。図５は、テストデ
ータ入力の初期画面を示す概略図、図６は、テストデー
タの入力ウインドウを示す概略図である。図５におい
て、表示されている図面は、図４で示したプロセスＭＰ
１の例で示したものである。

【００２６】テストを行なう図面を呼び出し、図面の表
示されているウインドウの上から２段目にあるメニュー
の「テストケース」を選択すると、環境設定部１によっ
てテストデータなどの入力ができるモードとなる。図示
されているウインドウの左端のコマンド欄が点線から実
線に変化する。また、図５に示されているように、テス
トデータ入力の初期画面が、一つのウインドウとして表
示される。

【００２７】図５に図示されている図面では、データＤ
２の値によって、プロセスＬＰ１とＬＰ２を切り換える
ことが記述されており、処理の流れとしては、プロセス
ＬＰ１を通過するパスと、プロセスＬＰ２を通過するパ
スの２通りがある。そのため、それぞれのパスにしたが
ったテストデータの入力が行なえる必要がある。そのた
め、テストデータを入力するウインドウには、パスの欄
に「１」、「２」の表示があり、ユーザはポインティン
グデバイスなどで指示することにより、パスを選択し
て、テストデータの入力を行なうことができる。選択さ
れたパスは、図面上で太線によって表示され、また、通
過するプロセス、例えば、ＬＰ１が反転表示されるの
で、選択したパスを確認することができる。入力する必
要のあるデータ項目は、データフローダイアグラムと、
データ構造定義の記述に基づいて自動的に設定される。

【００２８】テストデータ入力のウインドウにおいて、
入力したいデータの欄をポインティングデバイスなどで
指示すると、図６に示されているようなテストデータの
入力のためのウインドウが開き、テストデータを入力す
ることができる。入力すべきデータ数や、データ型など
は、データ構造定義の記述に基づいて自動的に設定され
る。実際のデータの入力は、基本的にはユーザがキーボ
ードなどから入力することになる。しかし、図６に図示
されているデータＤ１のように、多数の入力を必要とす
る場合、入力作業に手間がかかる。入力の手間を軽減す
るため、ウインドウ中の「生成式」を選択することによ
って、ある生成式に基づいた値を、それぞれのテストデ
ータの値とすることができる。また、「ランダム」を選
択することによって、ランダムなデータをテストデータ
として用いることも可能である。テストデータの順序も
「順序がえ」を選択することによって、行なうことがで
きる。さらに、入力したデータの傾向を確認したいとき
のために、「グラフ」を選択することにより、入力され
たテストデータをグラフ表示でき、視覚的にテストデー
タの確認を行なうことができる。

【００２９】上述の例では、図面ＭＰ１についてのテス
トデータの入力について説明した。この説明では、テス
トを行なう図面を図面ＭＰ１と仮定して、テストデータ
の設定を行なっている。テストを行なう図面は、どの階
層の、どの図面でも良く、ユーザが指定することとな
る。また、複数の図面についてテストデータを設定する
ことも、もちろん可能である。設定されたテストデータ
は、データ管理部２で保管、管理される。

【００３０】テストデータの設定の他に、デバッグのた
めの各種の機能を選択的に設定することができる。例え
ば、この実施例では、ブレークポイントの設定や、トレ
ースポイント、ウォッチポイントの設定ができる。これ
らは、従来のソースコードレベルのテスト、デバッガに
もあるような機能である。しかし、本発明では階層的
に、しかもビジュアルに表現されたプログラム仕様をデ
バッグの対象としているため、それぞれの設定は、各ポ
イントの設定したい図面上で、図形を選択することで行
なうこととなる。すなわち、これらのポイントの設定
は、テストする図面のみに限らず、下位に存在する図面
に対しても設定できる。

【００３１】ブレークポイントは、指示されたプロセス
が実行される場合、実行を中断することを指示するもの
であり、「ＢＲＥＡＫ」を選択し、中断したいプロセス
を選択することにより、ブレークポイントが設定され
る。

【００３２】トレースポイントは、指定されたプロセス
が実行されたことを示すメッセージを表示することを指
示する点であり、実行時のプロセスの実行順序などを知
ることができる。ユーザは、「ＴＲＡＣＥ」を選択し、
指示したいプロセスを選択することにより、トレースポ
イントを設定することができる。

【００３３】ウォッチポイントは、指定されたデータ
に、どのような値が設定されるかを実行時に監視する点
であり、実行時におけるデータの値の変化などを知るこ
とができる。「ＷＡＴＣＨ」を選択し、データの流れを
示す線を選択することで、ウォッチポイントを設定する
ことができる。

【００３４】これらの機能の設定は、図面に１つとは限
らず、いくつも設定することができる。各選択枝の表示
は単なる例示にすぎず、分かりやすいように表示すれば
良い。また、トレースポイントやウォッチポイント通過
の表示方法も種々の方法が考えられ、例えば図面上のプ
ロセスを示す矩形や、データの流れを示す矢線の表示を
強調表示したり、別のウインドウを開いて、そのウイン
ドウに表示するようにしても良い。さらに、上述の機能
以外のデバッグ機能を組み込むことももちろん可能であ
る。上述の機能を適宜用いながら、対話的にテスト、デ
バッグを進めることができる。

【００３５】さらに、テスト実行時に下位の実行すべき
プロセスが、まだ開発されていないなどで、存在しない
場合、実行すべきプロセスの代わりに、実行すべきプロ
セスが出力すべき擬似データをセットし、あたかもプロ
セスが存在していたように実行させることができる。こ
の機能は一般にスタブ化と呼ばれる機能であり、図面の
表示されているウインドウの上から２段目のメニュー中
の「スタブ化」を選択することにより、スタブ化するプ
ロセスの出力データを設定することができる。以上のよ
うなデバッグの環境設定を行なったのち、テストの実行
を行なうこととなる。

【００３６】実際のテストは、図１の実行制御部３によ
って行なわれる。ウインドウ左欄上の「実行」をユーザ
が選択すると、実行のモードとなる。図７はプロセスの
実行過程を示す概略図である。プロセスの実行は、概念
的には、図７に図示されているように、実行すべきプロ
セスＡに対して、テストデータを入力することによって
行なわれ、プロセスＡの出力する実行結果を保存し、ユ
ーザの要求によって表示する。しかし、プロセスＡに対
応する実行形式のプログラムは、図１で説明したよう
に、実行イメージ８内に存在するため、実行制御部３
が、プロセスＡに対応する実行イメージ内の関数Ａを実
行するように、実行の指示と、入力とすべきテストデー
タを実行イメージへ渡す。実行イメージでは、関数Ａを
実行し、実行結果を実行制御部３に渡す。これらの動作
によって、ユーザはプログラム仕様上のプロセスの実行
を、実行イメージを意識せずに行なうことができ、また
プロセスの実行結果を得ることによって、プログラム仕
様上でのデバッグを行なうことができる。

【００３７】実行制御部３は、このように実行イメージ
とのデータの受け渡しを行なっており、指定されたプロ
セスに対して、実行の指示と、該当するテストデータの
プロセスへの入力、および実行結果の受け取りを、プロ
セス間通信により行っている。

【００３８】図８は、テストの実行過程を示す模式図で
ある。テスト対象図面としては、図２（Ａ）に示した図
面を、図面Ｂとしては、図４に示した図面を仮定してい
る。なお、図２（Ａ）において、入力処理プロセスＩＰ
１〜ＩＰ３は、まとめてプロセスＩＰとして示してい
る。図８において、ユーザから「ＧＯ」の指示がある
と、プロセスＩＰ、ＭＰ１、ＭＰ２、ＯＰの順でそれぞ
れのプロセスが実行され、最後のプロセスを終了すると
停止する。ユーザから「ＳＴＯＰ」が指示されると、実
行中のプロセスの実行後に実行を中止することができ
る。また、「ＳＴＥＰ」を指示することにより、各プロ
セスを一つずつ実行することができる。

【００３９】プロセスＭＰ１、ＭＰ２には、下位のプロ
セスが存在するが、ユーザからは、一つのプロセスとし
て実行を行なうことができる。しかし、デバッグのため
に下位のプロセスの挙動を知りたいこともある。このよ
うなときは、「ＳＴＥＰ」実行中に、「ＩＮ」を指示す
ると、下位の図面がウインドウ表示され、下位の図面中
の各プロセスごとの実行を指示できる。また、「ＯＶ」
を指示することにより、上位の図面に戻り、もとの図面
上のプロセスの実行を継続することができる。例えば、
図８に示されている例では、「ＳＴＥＰ」を指示してプ
ロセスＩＰを実行し、その後、「ＩＮ」を指示すると、
図面Ｂがウインドウ表示される。そして、「ＳＴＥＰ」
の指示で図面Ｂ上のプロセスＬＰ１またはプロセスＬＰ
２のどちらかが実行される。さらに、「ＯＶ」指示によ
って上位図面に戻り、実行を続けることができる。

【００４０】各プロセスの実行により出力される出力デ
ータは、図１で説明したように、各プロセスの実行毎に
実行イメージ８から実行制御部３に送られ、テスト結果
として、データ管理部２において保管、管理される。得
られたテスト結果は、必要に応じてユーザが参照するこ
とができる。例えば、図５において、虫めがねのアイコ
ンで示された「ＤＴ」を選択し、データの流れを示して
いる矢印のついた線の上を選択すると、選択した線に対
応するデータの表示が行なえる。この機能により、２つ
のプロセスの間で受け渡されたデータの値や状態、下位
のプロセスにおけるデータの値や状態などを検証するこ
とができ、デバッグの際に有益である。

【００４１】また、各プロセスの実行時には、環境設定
時にデバッグ用のコマンド、すなわち、ブレークポイン
ト、トレースポイント、ウォッチポイントなどが指定さ
れていると、各コマンドに応じた動作が行なわれる。例
えば、図８において、プロセスＬＰ１にトレースポイン
トが指定されていて、実行時にプロセスＬＰ１が実行さ
れれば、ユーザに対してプロセスＬＰ１が実行された旨
のメッセージを表示することとなる。

【００４２】最後に、図１の実行イメージ８について説
明する。実行イメージ８は、実行制御部３からの実行指
示およびテストデータをプロセス間通信により受け取
り、指示にしたがってプロセスの実行を行なう。図９
は、実行イメージの作成過程を示すブロック図である。
図１のプログラム仕様作成手段６によって作成されたプ
ログラム仕様は、プログラム仕様からソースコードへの
変換手段により、ソースコードに変換される。変換の際
に、プログラム仕様上でプログラム部品の使用を指定さ
れている場合、部品データベース７内にあるプログラム
部品を、プログラム仕様から変換されたソースコードに
合成し、一つのソースコードにまとめる。できあがった
ソースコードは、コンパイラによりコンパイルし、リン
カによりライブラリなどとリンクされ、実行形式の実行
イメージ８を得ている。

【００４３】図１０は、実行イメージの構成図である。
図中、３は実行制御部、８は実行イメージ、１１は関
数、１２は関数ドライバ、１３は通信部である。図９の
ような過程を経て出来上がった実行イメージは、実際に
実行される関数１１のほか、実行制御部３とのプロセス
間通信を行なう通信部１３や、指定された関数を起動す
るための関数ドライバ１２も存在し、本発明のデバッガ
とは別の、一つのタスクとして実行される。関数１１
は、プログラム仕様の各プロセスに対応して生成されて
おり、プログラム仕様が階層的であるのと同様に、関数
１１も階層的な構造となっている。図１０においては、
関数Ｆ（Ａ）の下位には関数Ｆ（Ｂ）とＦ（Ｃ）が存在
し、さらに関数Ｆ（Ｂ）の下位には関数Ｆ（Ｄ）とＦ
（Ｅ）が、関数Ｆ（Ｃ）の下位には関数Ｆ（Ｆ）とＦ
（Ｇ）が存在する。

【００４４】関数ドライバ１２は、各関数に対応して設
けられ、実行制御部３からの指示にしたがって、どの関
数でも実行させることができるようになっている。図１
０においては、関数Ｆ（Ａ）に対応して関数ドライバＤ
（Ａ）、関数Ｆ（Ｂ）に対応して関数ドライバＤ
（Ｂ）、．．．というように、それぞれの関数に対応し
た関数ドライバが設けられている。関数ドライバ１２
は、指示された関数に対応する関数ドライバを選択し、
各関数の実行と、各関数へのデータの入力、および各関
数から出力される実行結果を通信部１３に渡す機能を有
している。

【００４５】通信部１３は、実行制御部３からの関数の
実行指示と、入力すべきデータを関数ドライバ１２に渡
し、関数１１の実行後、実行結果を関数ドライバ１２か
ら受け取って、実行制御部３に送る機能を有する。

【００４６】テスト実行時の動作を説明する。実行制御
部３からのプロセスの指示や、テストデータは、プロセ
ス間通信によって通信部１３に伝達され、通信部３は、
これらのデータを受け取って、関数ドライバ１２へ渡
す。関数ドライバ１２では、指示されたプロセスに対応
したドライバを選択し、該当するドライバに関数の実行
を指示するとともに、入力すべきデータを渡す。指示さ
れた関数１１は実行され、実行結果を関数ドライバ１２
に渡し、通信部３を介して実行制御部３に伝達する。

【００４７】このように、実行イメージ内に各関数に対
応した関数ドライバ１２を有しているから、プログラム
仕様上で指示されたプロセス毎の実行を可能にしてお
り、また各プロセス毎に実行結果を得ることができるよ
うになっている。

【００４８】

【発明の効果】以上の説明から明らかなように、本発明
によれば、プログラム仕様と実際に動く実行イメージ中
の関数とを対応づけ、入力されたテストデータを用いて
プログラム仕様上のプロセスを実行し、その結果を見る
ことができるから、プログラム仕様上でのデバッグを行
なうことができる。また、デバッグの対象が、視覚的な
ダイアグラムで記述されたプログラム仕様なので、視覚
的なデバッグを実現でき、効率よくデバッグを行なうこ
とができる。さらに、テストデータの入力作成、プログ
ラム仕様の表示、プロセスの実行、実行結果の表示など
を対話的に、しかも簡単に行なえるから、効率の良いデ
バッグを行なうことができる、という効果がある。

【図面の簡単な説明】

【図１】本発明のソフトウェアデバッグ装置の一実施例
を示す概略図である。

【図２】本実施例において用いるプログラム仕様の説明
図である。

【図３】プロセスの階層構造を示す概略図である。

【図４】下位展開されたプロセスの図面の概略図であ
る。

【図５】テストデータ入力の初期画面を示す概略図、

【図６】テストデータの入力ウインドウを示す概略図で
ある。

【図７】プロセスの実行過程を示す概略図である。

【図８】テストの実行過程を示す模式図である。

【図９】実行イメージの作成過程を示すブロック図であ
る。

【図１０】実行イメージの構成図である。

【符号の説明】

１環境設定部２データ管理部３実行制御部４ユーザインタフェース部５プログラム仕様管理部６プログラム仕様作成手段７部品データベース８実行イメージ

Claims

【特許請求の範囲】

【請求項１】プログラム仕様に対してテスト、デバッ
グを行なうソフトウェアデバッグ装置において、プログ
ラム仕様の入力、管理を行なうプログラム仕様管理部
と、テストデータの入力作成を対話的に行なう環境設定
部と、対話的な指示に基づき、入力データの割当と、実
行可能な状態に変換されたプログラム仕様の実行を制御
する実行制御部と、環境設定部において作成されたテス
トデータ、および実行結果を記憶し、管理するデータ管
理部と、対話的なデータの表示および指示を行なうユー
ザインタフェース部、を有することを特徴とするソフト
ウェアデバック装置。