JPH1145193A - ソフトウエア開発支援方法およびソフトウエア開発支援装置および記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】ユーザアプリケーションの実行中断（ブレー
ク）ポイントの設定および誤動作ポイントの検出が容易
に行え、デバッグ作業の負担が軽減できるソフトウエア
開発支援装置を提供する。 【解決手段】システムで実行されるソフトウエアのタス
クの状態遷移に基づく前記タスクの禁止動作の条件を入
力する入力手段と、この入力手段で入力された条件に基
づき前記ソフトウエアのタスクの状態遷移に基づく前記
タスクの禁止動作のパターンを生成する生成手段と、前
記ソフトウエアの実行の際に前記ソフトウエア実行に基
づき発生するイベントに従って遷移させたタスクの状態
と前記生成されたパターンとに基づいて、前記ソフトウ
エアのタスクの禁止動作を検出する検出手段と、この検
出手段で禁止動作が検出されたとき、前記ソフトウエア
の実行の中断を指示する指示手段とを具備する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ＯＳの下で実行さ
れるユーザアプリケーションのデバッグに用いるソフト
ウエア開発支援装置に関する。

【０００２】

【従来の技術】ＯＳ（オペレーティングシステム）の下
で実行するユーザアプリケーションのデバッグ作業で
は、ＯＳの管理する複数のイベントの発生パターンを考
慮したデバッグ作業を行う必要がある。さらに、マルチ
タスクＯＳに至っては、各タスク状態遷移も考慮したデ
バッグ作業を行わなければならない。ここでいうデバッ
グ作業とは、プログラムのコンパイル時のエラーを修正
することではなく、コンパイルエラーは発生しないが実
行時の動作が異常である場合の不具合の修正作業につい
てである。通常は、ユーザがブレークポイントを定め、
ユーザアプリケーションの実行を中断し、その時点での
ＯＳ内部状態などを参照し、プログラムを修正するとい
う作業を繰り返す。

【０００３】すなわち、従来、ＯＳの下で実行するユー
ザアプリケーションのデバッグ作業では、ユーザが、不
具合の解決に有効であると判断した実行命令に、ブレー
クポイントを予め設定しておき、デバッガがその実行命
令の格納されている実行アドレスにブレーク命令を設定
した上で、ユーザアプリケーションの実行を行う。そし
て、ブレーク命令によるユーザアプリケーションの実行
中断時に、そのときのメモリや使用変数等、ＯＳ内部状
態を参照し、ユーザアプリケーションの具体的な誤動作
の原因の検証を行っている。つまり、どのようなイベン
トがどのような順序で発生したことが不具合の原因であ
るかといったことを、ユーザ自身が分析するようになっ
ていた。

【０００４】

【発明が解決しようとする課題】しかしながら、上記の
ような従来のデバッガでは、ユーザーが予め誤動作の原
因と考えられる特定の実行命令を推測した上で、ブレー
クポイントを設定し、ユーザアプリケーションの実行中
断時に、ユーザ自身が具体的な誤動作の原因を検証しな
ければならないという欠点がある。すなわち、ユーザ自
身による誤動作原因の推測と検証という試行錯誤的な作
業が必要となるため、デバッグ作業が円滑に行われず、
ユーザアプリケーション全体としての生産性が低下して
しまう恐れがある。

【０００５】そこで、本発明は、上記問題点に鑑みてな
されたもので、ユーザアプリケーションの実行中断（ブ
レーク）ポイントの設定および誤動作ポイントの検出、
さらに誤動作検出時のＯＳ内部状態の参照が容易に行
え、デバッグ作業の負担が軽減できるソフトウエア開発
支援方法およびそれを用いたソフトウエア開発支援装置
を提供することを目的とする。

【０００６】

【課題を解決するための手段】本発明のソフトウエア開
発支援方法は、システムで実行されるソフトウエアのタ
スクの状態遷移に基づく前記タスクの禁止動作のパター
ンを生成し、前記ソフトウエアの実行の際に前記ソフト
ウエア実行に基づき発生するイベントに従って遷移させ
たタスクの状態と前記生成されたパターンとに基づい
て、前記ソフトウエアのタスクの禁止動作を検出したと
き、前記ソフトウエアの実行の中断を指示することによ
り、システム上で実行されるソフトウエアの実行中断
（ブレーク）ポイントの設定および誤動作ポイントの検
出が容易に行え、デバッグ作業の負担が軽減できる。

【０００７】また、本発明のソフトウエア開発支援装置
は、システムで実行されるソフトウエアのタスクの状態
遷移に基づく前記タスクの禁止動作の条件を入力する入
力手段と、この入力手段で入力された条件に基づき前記
ソフトウエアのタスクの状態遷移に基づく前記タスクの
禁止動作のパターンを生成する生成手段と、前記ソフト
ウエアの実行の際に前記ソフトウエア実行に基づき発生
するイベントに従って遷移させたタスクの状態と前記生
成されたパターンとに基づいて、前記ソフトウエアのタ
スクの禁止動作を検出する検出手段と、この検出手段で
禁止動作が検出されたとき、前記ソフトウエアの実行の
中断を指示する指示手段と、を具備したことにより、シ
ステム上で実行されるソフトウエアの実行中断（ブレー
ク）ポイントの設定および誤動作ポイントの検出が容易
に行え、デバッグ作業の負担が軽減できる。

【０００８】

【発明の実施の形態】以下に、本発明の実施形態につい
て図面を参照して説明する。図１は、本実施形態に係る
ソフトウエア開発支援装置の構成例と、そのソフトウエ
ア開発支援装置を用いて、ＯＳ（マルチタスクＯＳ）上
で実行されるユーザアプリケーションのデバッグを行う
場合の全体の構成を概略的に示したものである。以下、
図１のマルチタスクＯＳ２、ユーザアプリケーション
１、ソフトウエア開発支援装置３のそれぞれについて説
明する。 （ａ）マルチタスクＯＳ 図１に示したように、マルチタスクＯＳ２のソフトウエ
ア開発支援装置３の動作に関わる主な構成部は、タスク
実行スケジューリング部４、ＯＳ内部イベント発生部
５、タスク実行制御部６の３つの処理部と、内部記憶で
あるＯＳ内部状態記憶部７から構成される。なお、図１
のマルチタスクＯＳの構成は、本実施例を説明する上で
必要な部分以外は削除し、簡略化したものである。

【０００９】（ａ−１）タスク実行スケジューリング部 タスク実行スケジューリング部４は、ユーザアプリケー
ション１からのシステムコールや外部機器などからの割
込みなどのイベントを受けて、タスク実行優先度を考慮
したタスク実行スケジューリングを行う。スケジューリ
ングの結果、次に実行すべきタスクをタスク実行制御部
６に伝える。このスケジューリングの過程で発生するタ
スクの状態遷移やセマフォの状態変更などのＯＳ内部状
態の変化は、ＯＳ内部状態記憶部７に逐次記憶される。
図２にＯＳ内部状態の記憶例を示す。ＯＳ内部状態は、
マルチタスクＯＳ２が、システムコールやタスク実行ス
ケジューリングなどのサービスを提供するために用いる
情報であり、ユーザアプリケーション１で定義された全
てのオブジェクトに関する情報がオブジェクトごとに格
納されている。図２では、タスクＡ、タスクＢ、タスク
Ｃ、セマフォＰの４つのオブジェクトの状態を格納した
場合の例を示してある。これら各情報の詳細について
は、後述する。

【００１０】また、タスク実行スケジューリング部４
は、システムコール発行イベント、タスク状態遷移イベ
ント、セマフォ状態変更イベントの他、外部機器からの
割込みなど、タスク実行スケジューリングに影響を及ぼ
す全てのイベントをＯＳ内部イベントとしてＯＳ内部イ
ベント発生部５に対して発行する。システムコール発行
イベントは、ユーザアプリケーション１からシステムコ
ールが発行された時に発生するイベントである。タスク
状態遷移イベントは、タスク実行スケジューリングの結
果、タスクの状態が変化した場合に発生するイベントで
ある。セマフォ状態変更イベントは、セマフォの状態が
変更された場合に発生するイベントである。

【００１１】（ａ−２）タスク実行制御部 タスク実行制御部６は、タスク実行スケジューリング部
４、ソフトウエア開発支援装置３などマルチタスクＯＳ
２外部からの要求によって、指定タスクに対して実行開
始、実行中断、実行停止などの実行制御を行う。

【００１２】（ａ−３）ＯＳ内部イベント発生部 ＯＳ内部イベント発生部５は、タスク実行スケジューリ
ング部４から発行されたＯＳ内部イベントを、ソフトウ
エア開発支援装置３などのマルチタスクＯＳ２外部のア
プリケーションから読み出すためのインタフェースを提
供する。

【００１３】マルチタスクＯＳ２がユーザアプリケーシ
ョン１に対して提供するオブジェクトには、タスクや割
込みハンドラ、セマフォ、メールボックスなどがある。
このうち、本実施形態で用いるタスクとセマフォの２種
類のオブジェクトについて、その仕組やＯＳ内部状態の
詳細について説明する。

【００１４】タスクは、プログラムの実行単位であり、
マルチタスクＯＳ２は、タスク実行スケジューリングに
より、タスクを切り替えながら、ユーザアプリケーショ
ン１を実行する。

【００１５】セマフォは、同時に複数のタスクからのア
クセスが制限されるような共有資源へのアクセス権をタ
スクが獲得するための排他制御機能を提供する。ＯＳ内
部状態は、ユーザアプリケーション１の実行中に、マル
チタスクＯＳ２によって随時更新され、タスク制御ブロ
ックやセマフォ制御テーブルといったユーザアプリケー
ションで定義された全てのオブジェクトの状態を保持し
ている。

【００１６】タスク制御ブロックは、図３に示すよう
に、タスクＩＤ、タスク状態、タスク優先度などの属性
を持っている。タスクＩＤは、タスクを識別するための
識別子である。タスク状態は、タスクの現在の状態を示
す。タスク状態には、実行状態（ＲＵＮ）、実行可能状
態（ＲＥＡＤＹ）、待ち状態（ＷＡＩＴ）などの種類が
ある。タスク優先度は、タスクの実行優先度を示してい
る。例えば、マルチタスクＯＳ２が提供するタスク実行
スケジューリング機能において、２つ以上のタスクが同
時に実行可能状態となった場合、マルチタスクＯＳ２
は、同時に実行可能となったタスクのタスク優先度を参
照し、優先度が最も高いタスクを実行状態とする。

【００１７】セマフォ制御テーブルは、図４に示すよう
に、セマフォＩＤ、セマフォカウンタ値などの属性を持
っている。セマフォＩＤは、セマフォを識別するための
識別子である。セマフォカウンタ値は、現在のセマフォ
カウンタの値を示している。本実施形態では、セマフォ
の仕組を簡略化し、セマフォカウンタ値は、「０」と
「１」の２つの値のみをとるものとする。この場合、セ
マフォカウンタ値が「１」のときは、セマフォを獲得す
ることにより、どのタスクも共有資源へのアクセスが可
能であり、何れかのタスクがセマフォを取得するとセマ
フォカウンタ値が「０」となる。セマフォカウンタ値が
「０」のときは、どのタスクもセマフォを獲得できず、
現在セマフォを取得しているタスクがセマフォを開放す
るまでは、セマフォを要求したタスクはセマフォ待ちの
状態になる。そして、セマフォを獲得しているタスクが
セマフォを開放すると、セマフォ待ちのタスクがセマフ
ォを獲得し、共有資源へのアクセスが可能となる。 （ｂ）ユーザアプリケーション ユーザアプリケーション１は、ユーザが作成したマルチ
タスク・アプリケーションである。図５は本実施形態に
おいてデバッグの対象とするユーザアプリケーションの
構成を概念的に示したものである。図６は図５のユーザ
アプリケーション実行中の単位時間ごとの各オブジェク
トの状態変化、及び発生したＯＳ内部イベントを示した
タイミングチャートである。

【００１８】図５に示すように、ユーザアプリケーショ
ン１は、タスクＡ、タスクＢ、タスクＣ、タスクＤの４
つのタスクと、セマフォＰの合わせて５つのオブジェク
トによって構成される。共有資源は、同時に２つのタス
クからアクセスできないものとし、セマフォＰはこのた
めの排他制御に用いる。

【００１９】なお、ここで、タスクとは、ある機能を実
現するための一単位のプログラム、あるいはモジュール
である。各タスクのタスクＩＤ、タスク優先度、タスク
状態の初期値は、図５中に示した通りである。タスク優
先度は「１」以上の整数値で、「１」が最高の実行優先
度を示すものとする。例えば、タスクＡのタスクＩＤは
「＃１」であり、タスク優先度は「１」で最高の実行優
先度であり、タスク状態は、ＲＵＮ状態であることを示
している。他のタスクについても同様に示してある。

【００２０】セマフォＰのセマフォＩＤ、セマフォカウ
ンタ値の初期値は、図５に示した通りである。セマフォ
ＩＤは「＃９９」であり、セマフォカウンタ値の初期値
は「０」である。

【００２１】図６に示したタイミングチャートは、縦軸
にユーザアプリケーションで定義したオブジェクトを、
横軸に時刻０００ｍ秒〜時刻９００ｍ秒を１００ｍ秒刻
みでとり、１００ｍ秒単位で各時刻における各タスクの
タスク状態や各タスクから発行されたシステムコールの
種類、およびセマフォの状態を示している。タスク状態
は、実線がＲＵＮ状態、波線がＷＡＩＴ状態、破線がＲ
ＥＡＤＹ状態でそれぞれ示してある。また、システムコ
ールの発行は、発行システムコールの種類とともに、発
行元タスクの発行時刻への矢印で示している。例えば、
時刻０００ｍ秒における各タスクのタスク状態は、タス
クＡがＲＵＮ状態、タスクＢがＷＡＩＴ状態、タスクＣ
がＷＡＩＴ状態、タスクＤがＲＥＡＤＹ状態であり、セ
マフォＰのセマフォカウンタ値は「０」で、この状態か
ら時刻１００ｍ秒にタクスＡがシステムコールｓｉｇ
ｓｅｍ（＃９９）を発行したことにより、タスクＢの状
態がＷＡＩＴ状態からＲＥＡＤＹ状態に遷移したことを
読み取ることができる。この様にして、タスクＡ、タス
クＢ、タスクＣ、タスクＤの４つのタスクは、マルチタ
スクＯＳ２が提供するシステムコールを用いて、実行タ
スクの切り替えや、セマフォを用いた共有資源へのアク
セス行う。

【００２２】次に、図６のタイミングチャートに基づ
く、ユーザアプリケーション１の振舞いについて説明す
る。 時刻０００ｍ秒：初期状態であり、タスクＡがセマフォ
Ｐ取得中でＲＵＮ状態、タスクＢがセマフォＰ取得待ち
でＷＡＩＴ状態、タスクＣがＷＡＩＴ状態、タスクＤが
ＲＥＡＤＹ状態である。セマフォＰのセマフォカウンタ
値は、タスクＡがセマフォＰを取得中であるため、
「０」である。

【００２３】時刻１００ｍ秒：タスクＡがシステムコー
ルｓｉｇ＿ｓｅｍ（＃９９）を発行し、セマフォＰが開
放され、セマフォＰ待ち状態であったタスクＢがＲＥＡ
ＤＹ状態となる。しかし、タスクＡの方が実行優先度が
高いため、タスクの切り替えは発生しない。

【００２４】時刻２００ｍ秒：タスクＡがシステムコー
ルｗｕｐ ｔｓｋ（＃３）を発行し、タスクＣを起床
し、タスクＣはＲＥＡＤＹ状態となる。 時刻３００ｍ秒：タスクＡがシステムコールｓｌｐ ｔ
ｓｋ（）を発行し、タスクＡがＷＡＩＴ状態となり、タ
スクＡ以外のタスクでＲＥＡＤＹ状態であるタスクのう
ち、実行優先度が最も高いタスク、すなわちタスクＢが
ＲＵＮ状態となる。

【００２５】時刻４００ｍ秒：タスクＢがシステムコー
ルｓｉｇ ｓｅｍ（＃９９）を発行し、セマフォＰが開
放され、セマフォＰのセマフォカウンタ値が「１」とな
る。 時刻５００ｍ秒：タスクＢがシステムコールｓｌｐ ｔ
ｓｋ（）を発行し、タスクＢがＷＡＩＴ状態となり、タ
スクＢ以外のタスクでＲＥＡＤＹ状態であるタスクのう
ち、実行優先度が最も高いタスク、すなわちタスクＣが
ＲＵＮ状態となる。

【００２６】時刻６００ｍ秒：タスクＣがシステムコー
ルｗａｉ ｓｅｍ（＃９９）を発行し、セマフォＰを取
得しようとするが、セマフォＰのセマフォカウンタ値が
「１」であるため、タスクＣはセマフォ待ちとはなら
ず、タスクＣがセマフォＰを取得する。この結果、セマ
フォＰのセマフォカウンタ値は「０」となる。

【００２７】時刻７００ｍ秒：タスクＣがシステムコー
ルｓｌｐ ｔｓｋ（）を発行し、タスクＣがＷＡＩＴ状
態となり、タスクＡ以外のタスクでＲＥＡＤＹ状態であ
るタスクのうち、実行優先度が最も高いタスク、すなわ
ちタスクＤがＲＵＮ状態となる。

【００２８】時刻８００ｍ秒：タスクＤがシステムコー
ルｗｕｐ ｔｓｋ（＃１）を発行し、タスクＡが実行可
能となるが、タスクＡはタスクＤよりも実行優先度が高
いため、タスクＤがＲＥＡＤＹ状態となり、タスクＡが
ＲＵＮ状態となる。

【００２９】時刻９００ｍ秒：ユーザアプリケーション
の実行終了である。結果として、各オブジェクトの状態
は、タスクＡがＲＵＮ状態、タスクＢがＷＡＩＴ状態、
タスクＣがセマフォＰを取得中でＷＡＩＴ状態、タスク
ＤがＲＥＡＤＹ状態となる。セマフォＰのセマフォカウ
ンタ値は「０」であり、タスクＣがセマフォＰを取得中
である。

【００３０】次に、以上説明したようなユーザアプリケ
ーション１を、図１に示した構成のソフトウエア開発支
援装置３を用いて具体的にデバッグを行う場合の動作手
順を説明する。なお、本実施形態では、ソフトウエア開
発支援装置３に次の２つのブレークパターンを設定す
る。

【００３１】・ 第１のブレークパターン（第１の制約
条件）：タスクＢとタスクＣは、同時に実行可能となら
ない。 ・ 第２のブレークパターン（第２の制約条件）：タス
クＣは、セマフォＰをアクセスしない。

【００３２】ソフトウエア開発支援装置３は、ユーザア
プリケーション１の実行中に、これらのブレークパター
ンのうち、どちらか１つが不成立となった場合に、ユー
ザアプリケーション１の実行を中断するように振舞う。 （ｃ）ソフトウエア開発支援装置 図１に示すように、ソフトウエア開発支援装置３は、ブ
レークパターン入力部８、ブレークパターン生成部１
２、ＯＳ制御部１７、ブレーク情報出力部２０、ＯＳ内
部状態読取部１３、イベント読取部１４、トレース情報
出力部１８の７つの処理部と、ブレークパターンライブ
ラリ記憶部１０、ブレークパターン情報記憶部１１、ア
プリケーション情報記憶部９、イベント履歴情報記憶部
１９、の４つの外部記憶と、内部記憶であるＯＳ状態テ
ーブル記憶部１９から構成される。

【００３３】ソフトウエア開発支援装置３は、ユーザが
あらかじめソフトウエア開発支援装置３に設定した制約
条件（ユーザアプリケーションの禁止動作の条件）が、
ユーザアプリケーション１実行中に不成立となった場
合、すなわち、ブレーク状態を検出した場合（ユーザア
プリケーションの禁止動作を検出した場合）に、マルチ
タスクＯＳ２を制御し、ユーザアプリケーション１の実
行を一時中断するように構成されている。

【００３４】次に、ソフトウエア開発支援装置３の各部
の処理動作を図７に示す全体の処理の流れに沿って説明
する。 （ｃ−１）ブレークパターン入力部 ブレークパターン入力部８は、記憶部９に記憶されてい
るアプリケーション情報を参照し、ユーザに、記憶部１
０に記憶されているブレークパターンライブラリ、記憶
部１１に記憶されているブレークパターン情報の作成・
追加・修正・削除などの編集機能やそのためのユーザイ
ンタフェースを提供する。

【００３５】記憶部１０に記憶されているブレークパタ
ーンライブラリは、システムコール発行、タスク状態遷
移、セマフォ状態変更などのＯＳ内部イベントの発生と
その発生時刻におけるＯＳ内部状態などを入力イベント
とした状態遷移図で表されるブレークパターンの雛形の
セットである。例えば、図８や図９の形式でブレークパ
ターンの雛形が定義されている。

【００３６】例えば、制約条件が「特定の２つのタスク
が同時に実行可能とならない」であるときのブレークパ
ターンの雛形は、図８のように表すことができる。図８
において「同時に実行可能とならない（タスク、タス
ク）」が制約条件の表記方法であり、これに対応するブ
レークパターンの定義がその下に示した状態遷移図であ
る。状態遷移図では、Ｓ₀ は初期状態、Ｓ_E は終了状
態、その他のＳ_n はＳ₀ からＳ_E への遷移の途中過程の
状態である。図８のイベントとして示した表記の１つで
ある「タスク状態遷移：（％１）→実行可能」の表記
は、タスク状態遷移イベントが発生し、その内容は、第
１引数のタスク％１が実行可能となったことによるイベ
ントであることを表している。

【００３７】同様に、制約条件が「特定のタスクが特定
のセマフォをアクセスしない」であるときのブレークパ
ターンの雛形は、図９のように表すことができる。図９
において、イベント表記「システムコール発行：ｓｉｇ
ｓｅｍ（％１、％２）」は、システムコール発行イベ
ントが発生し、その内容が、ｓｉｇ ｓｅｍ（％１、％
２）であることによるイベントであることを表してい
る。ここで、％１はタスクＩＤ、％２はセマフォＩＤを
表している。

【００３８】記憶部１１に記憶されているブレークパタ
ーン情報は、図１０に示すように、図８や図９の制約条
件の表記の引数部分に、具体的なタスクＩＤ、セマフォ
ＩＤなどのオブジェクトＩＤを設定するためのものであ
る。

【００３９】例えは、図１０の「同時に実行可能となら
ない（＃２、＃３）」という表記は、タスクＢとタスク
Ｃが同時に実行可能とならないという第１の制約条件を
表しており、「アクセスしない（＃３、＃９９）」とい
う表記は、タスクＣがセマフォＰをアクセスしないとい
う第２の制約条件を表している。

【００４０】ブレークパターン入力部８のユーザインタ
フェースは、図８や図９の状態遷移図を含むブレークパ
ターンライブラリ、及び図１０のブレークパターン情報
に関する、作成・追加・修正・削除などの編集機能を実
装している。

【００４１】また、ブレークパターン入力部８は、ユー
ザが設定するブレークパターンの記入誤りチェックのた
めに、記憶部９に記憶されたアプリケーション情報を利
用する。

【００４２】アプリケーション情報は、デバッグ対象と
するユーザアプリケーション１全体に依存した情報であ
り、マルチタスクＯＳ２に依存した情報と、ユーザアプ
リケーション１に依存した情報を含む。マルチタスクＯ
Ｓ２に依存した情報は、図１１に示すような、マルチタ
スクＯＳ２が提供するシステムコールの種類、オブジェ
クトの種類、タスク制御ブロックの属性、セマフォ制御
ブロックの属性などの情報である。ユーザアプリケーシ
ョン１に依存した情報は、図１２及び図１３に示すよう
な、ユーザがユーザアプリケーション内で定義した全て
のオブジェクト（タスク、セマフォ）のオブジェクトＩ
Ｄとオブジェクト名の情報である。

【００４３】なお、本実施形態では触れないが、アプリ
ケーション情報は、ユーザアプリケーション１のコンパ
イル時に生成されるデバッグ情報や、これらの情報を提
供できるようなインタフェースを持ったマルチタスクＯ
Ｓ２から収集・作成してもよい。

【００４４】（ｃ−２）ブレークパターン生成部 ブレークパターン生成部１２は、記憶部１０、記憶部１
１にそれぞれ記憶されているブレークパターンライブラ
リとブレークパターン情報から、ブレーク状態検出部１
５に渡すためのブレークパターンを生成する。具体的な
イメージとしては、図８、図９に示した一般的なブレー
クパターンの雛形から、図１０のブレークパターン情報
を用いて、ブレーク状態検出部１５がデバッグのために
直接参照できる図１４、図１５に示したような具体的な
ブレークパターンを得ることである。

【００４５】ユーザアプリケーション１を実際に実行す
る前に、まず、上述したように、ブレークパターン入力
部８を介して所望の制約条件に基づき、ユーザは、ブレ
ークパターンの雛形、ブレークパターン情報の入力（作
成・追加・修正・削除などの編集も含む）を行う（ステ
ップＳ１）。そして、ブレークパターン生成部１２で
は、入力された一般的なブレークパターンの雛形から、
ブレークパターン情報を用いて、ブレーク状態検出部１
５がデバッグのために直接参照できるようなブレークパ
ターンを生成する（ステップＳ２）。

【００４６】さて、ユーザが、ソフトウエア開発支援装
置３からユーザアプリケーション１を実行状態にする際
には、まず、ユーザアプリケーション１の実行開始直後
またはユーザがあらかじめ設定したデバッグ開始ポイン
トでブレークするように従来技術によるブレークポイン
トを設定してから、ユーザアプリケーション１を実行状
態にする。この結果、ユーザアプリケーション１は実行
開始直後またはあらかじめ設定したデバッグ開始ポイン
トで実行を中断する。

【００４７】（ｃ−３） ＯＳ内部状態読取部 ＯＳ内部状態読取部１３は、ユーザアプリケーション１
のブレーク状態が検出されると（ユーザアプリケーショ
ンが実行される前に）、マルチタスクＯＳ２からＯＳ内
部状態を読み出し、ソフトウエア開発支援装置３内の内
部記憶であるＯＳ状態テーブル１６の初期値として書き
込む（ステップＳ１１）。ＯＳ状態テーブル１６は、図
２のＯＳ内部状態と同じ構造である。ＯＳ状態テーブル
１６への書き込みが完了すると、ＯＳ制御部１７を介し
てユーザアプリケーション１の実行を再開する（ステッ
プＳ１２）。

【００４８】図５に示したユーザアプリケーション１で
は、オブジェクトの初期状態、すなわちタスクＡ、タス
クＢ、タスクＣ、タスクＤ及びセマフォＰの初期状態が
読み込まれることになる。

【００４９】ＯＳ内部状態読取部１３は、ソフトウエア
開発支援装置３内部のＯＳ状態テーブル１６へのＯＳ内
部状態の書き込みが完了すると、ＯＳ制御部１７を介し
て、ユーザアプリケーション１の実行を開始する。

【００５０】（ｃ−４）ＯＳ制御部 ＯＳ制御部１７は、ＯＳ内部状態読取部１３やブレーク
状態検出部１５からの要求により、マルチタスクＯＳ２
のタスク実行制御部６を介して、ユーザアプリケーショ
ン１の全て、または一部のタスクについて、実行開始・
一時停止などの実行制御を行う。

【００５１】（ｃ−５）イベント読取部 イベント読取部１４は、ＯＳ制御部１７によって、ユー
ザアプリケーション１の実行が再開されると、マルチタ
スクＯＳ２内のＯＳ内部イベント発生部５から、ＯＳ内
部イベントの取得を開始し、取得したＯＳ内部イベント
をブレーク状態検出部１５に転送するほか、イベント履
歴情報として記憶部１９に格納する（ステップＳ１
３）。

【００５２】図１６は、図５のユーザアプリケーション
１を実行した場合に発生するＯＳ内部イベントから生成
したイベント履歴情報の一例を示したものである。図１
６において、１つのＯＳ内部イベントの履歴は、時刻、
イベント種別、イベント引数の３つのフィールドから構
成される。時刻フィールドは、当該イベントが発生した
時刻であり、イベント読取部１４によって付加されたフ
ィールドである。イベント種別フィールドは、イベント
ＩＤで表されており、各イベントＩＤの意味と、そのイ
ベントが持つイベント引数の内容は、図１７に示すよう
なテーブルを参照することにより解釈できる。例えば、
イベントＩＤが「１」のＯＳ内部イベントは、システム
コール発行イベントを意味しており、イベント引数とし
て、発行元タスクＩＤ、システムコール名、システムコ
ールの引数を持つ。なお、図１７では、本実施形態のユ
ーザアプリケーションの実行に関わらないＯＳ内部イベ
ントについては省略してある。図１６のイベント引数フ
ィールドには、図１７で示したイベント引数と対応した
内容で表記されている。例えば、図１６において、時刻
「１００」におけるシステムコール発行イベントのイベ
ント内容は、発行元タスクＩＤが「＃１」であり、シス
テムコール名がｓｉｇ ｓｅｍであり、システムコール
引数が「＃９９」である。ここで、システムコール発行
イベントの場合の引数の意味については、さらに図１８
に示すようなテーブルを参照することにより解釈でき
る。例えば、システムコールｓｉｇ ｓｅｍでは、引数
の数が「１」であり、その意味はセマフォＩＤであるこ
とが分かる。すなわち、前述の「＃９９」はセマフォＩ
Ｄである。

【００５３】この他、イベント読取部１４は、ブレーク
状態検出部１５へのＯＳ内部イベントの転送元を、格納
済みのイベント履歴情報記憶部１９に切り替えて転送す
ることが可能であり、また、トレース情報出力部１８を
介して、マルチタスクＯＳ２内のＯＳ内部イベント発生
部５から取得したＯＳ内部イベントを逐次ユーザにトレ
ース情報として提供することができる。

【００５４】（ｃ−６）トレース情報出力部 トレース情報出力部１８は、現在、イベント読取部１４
からブレーク状態検出部１５に伝えられているＯＳ内部
イベントを、例えば、図６に示すような図形的表記、ま
たは図１６に示すような文字表記にて、ユーザに逐次示
す。

【００５５】（ｃ−７）ブレーク状態検出部 ブレーク状態検出部１５は、イベント読取部１４から伝
えられたＯＳ内部イベントの情報に基づいて、ＯＳ状態
テーブル１６の内容を更新する（ステップＳ１４）。こ
れによって、ＯＳ状態テーブル１６には、マルチタスク
ＯＳ２内のＯＳ内部状態と同じ情報が保持され、その記
憶形式は図２と同様である。

【００５６】例えば、図６に示したタイミングチャート
において、時刻３００ｍ秒の直前では、マルチタスクＯ
Ｓ２内部のタスクＡのタスク状態はＲＵＮ状態である。
この状態で図１６の時刻３０３ｍ秒の内部イベントが発
生すると、マルチタスクＯＳ２内のタスクＡのタスク状
態はＷＡＩＴ状態に遷移する。ソフトウエア開発支援装
置３内でも同じように、ブレーク状態検出部１５がイベ
ント読取部１４から時刻３０３ｍ秒のイベント履歴情報
を受けると、ＯＳ状態テーブル１６に格納されているタ
スクＡのタスク状態をＲＵＮ状態からＷＡＩＴ状態に遷
移させる。すなわち、ブレーク状態検出部１５により、
ＯＳ状態テーブル１６の内容は、常に最新のマルチタス
クＯＳの内部状態と同じ状態が保持されることになる。

【００５７】ブレーク状態検出部１５は、前述のＯＳ状
態テーブル１６の内容の更新を行う際に、ユーザにより
ユーザアプリケーション実行前に設定されているブレー
クパターンの照合を行う（ステップＳ１４〜ステップＳ
１５）。その際、ブレーク状態検出部１５は、イベント
読取部１４から伝えられたイベントに基づいて、現在設
定されている全てのブレークパターンの状態を遷移させ
る。

【００５８】ここで、ブレーク状態検出部１５のブレー
ク状態の検出処理について説明する。第１のブレークパ
ターンは図１４、第２のブレークパターンは図１５に示
すような２つの状態遷移図として、例えば、ブレーク状
態検出部１５に格納されている。ブレーク状態検出部１
５は、ユーザアプリケーション実行開始前に、全てのブ
レークパターンの状態を初期化する。ブレークパターン
の状態を初期化すると、ブレークパターンの状態が、図
１４および図１５における初期状態Ｓ₀ となる。

【００５９】まず、図１４のブレークパターンから見て
みる。このブレークパターンは、「タスクＢとタスクＣ
が同時に実行可能とならない」というものであった。図
６のタイミングチャートにおいて、ユーザアプリケーシ
ョンが実行されて、１００ｍ秒が経過し、タスクＡがシ
ステムコールｓｉｇ ｓｅｍ（＃９９）を発行すると、
図１６の時刻１０３ｍ秒で示したタスク状態遷移イベン
ト「タスクＢ→ＲＥＡＤＹ」が、イベント読取部１４か
らブレーク状態検出部１５に伝えられる。ブレーク状態
検出部１５では、これを受けて図１４のブレークパター
ンの状態を、初期状態Ｓ₀ からＳ₁ に遷移させる。その
後、図６に示すように、時刻２００ｍ秒で、タスクＡが
システムコールｗｕｐ ｔｓｋ（＃３）を発行すると、
図１６の時刻２０３ｍ秒で示したタスク状態遷移イベン
ト「タスクＣ→ＲＥＡＤＹ」が発生し、ブレーク状態検
出部１５は、これを受けて図１４のブレークパターンの
状態を、初期状態Ｓ₁ からブレーク状態Ｓ_E に遷移させ
る。このとき、タスクＢ（＃２）とタスクＣ（＃３）が
同時に実行可能となり、ブレークパターンの状態がブレ
ーク状態となったので、ＯＳ制御部１７に対して、ユー
ザアプリケーション制御のための要求（ユーザアプリケ
ーションの実行の一時停止要求）を出す（ステップＳ１
６〜ステップＳ１７）。

【００６０】次に、図１５のブレークパターンを見てみ
る。このブレークパターンは、「タスクＣがセマフォＰ
をアクセスしない」というものであった。図６のタイミ
ングチャートにおいて、ユーザアプリケーションが実行
されて、６００ｍ秒が経過し、タスクＣがシステムコー
ルｓｉｇ ｓｅｍ（＃９９）を発行すると、図１６の時
刻６００ｍ秒で示したシステムコール発行イベント「タ
スクＣ→ｓｉｇ ｓｅｍ（＃９９）」が、ブレーク状態
検出部１５に伝えられ、これを受けて図１５のブレーク
パターンの状態を、初期状態Ｓ₀ からブレーク状態Ｓ_E
に遷移させる。このとき、タスクＣ（＃３）がセマフォ
Ｐをアクセスし、ブレークパターンの状態がブレーク状
態となったので、ＯＳ制御部１７に対して、ユーザアプ
リケーション制御のための要求（ユーザアプリケーショ
ンの実行の一時停止要求）を出す（ステップＳ１５〜ス
テップＳ１７）。

【００６１】なお、ブレークパターンは、複数同時に設
定することが可能で、この場合、イベントとＯＳ状態テ
ーブル１６の内容に応じて、全てのブレークパターンの
状態が遷移し、いずれか１つのブレークパターンの状態
がブレーク状態Ｓ_E に遷移した時に、ブレーク状態検出
部１５は、ＯＳ制御部１７に対してユーザアプリケーシ
ョン制御のための要求を出す。 （ｃ−８）ブレーク情報出力部 ブレーク情報出力部２０は、ブレーク状態検出部１５で
ブレーク状態が検出されたとき、図１９に示すように、
ブレークのトリガーとなったブレークパターンやプログ
ラム中の発生箇所をブレーク時のＯＳ状態テーブル１６
の内容などの情報を出力する（ステップＳ１８）。

【００６２】図１９は、第１のブレークパターンに基づ
くブレーク状態が検出された場合のブレーク情報出力部
２０を構成するユーザインタフェイスの１つであるブレ
ーク情報出力画面の一例である。図１９において、画面
最上部にトリガーとなったブレークパターンとユーザア
プリケーション内のイベント発生箇所が表示されてい
る。「同時に実行可能とならない（タスクＢ、タスク
Ｃ）ｉｎタスクＡ」という表記は、タスクＡ内でタスク
ＢとタスクＣが当時に実行可能となるような、ＯＳ内部
イベントが発生したことを示している。またその下に
は、ユーザアプリケーション１のプログラムのどの処理
がＯＳ内部イベント発生のトリガーとなったかが示され
ている。網掛け部分はブレークのトリガーとなった処理
で、この場合、前述したように、図６の時刻２００ｍ秒
におけるタスクＡのシステムコールｗｕｐ ｔｓｋ（＃
３）の発行であることが読みとれる。

【００６３】このようにして、ブレーク情報の出力が終
了すると、次に、ＯＳ内部状態読取部１３は、マルチタ
スクＯＳ２からＯＳ内部状態を読み出し、ソフトウエア
開発支援装置３内の内部記憶であるＯＳ状態テーブル１
６の初期値として書き込み（ステップＳ１１）、この書
き込みが終了すると、ブレーク状態検出部１５からの要
求に応じて、ＯＳ制御部１７はユーザアプリケーション
１の実行の再開を要求する（ステップＳ１２）。以下、
前述同様の処理動作が続行される。

【００６４】なお、ユーザアプリケーション１のプログ
ラムにおいて、デバッグ対象区間を指定することによ
り、デバッグ作業の効率化を図ることができる。 （ｄ）他の実施形態 図２０に、図７に示した本発明に係るＯＳの下で実行さ
れるユーザアプリケーションのデバッグに用いるソフト
ウエア開発支援方法を実現するコンピュータシステムの
構成を示す。このコンピュータシステムは、例えば、パ
ーソナルコンピュータであり、演算処理を司るＣＰＵ１
００１と、キーボード、ポインティングデバイスおよび
マイクロフォンなどの入力部１００２と、ディスプレイ
およびスピーカなどの出力部１００３と、主記憶として
のＲＯＭ１００４およびＲＡＭ１００５と、外部記憶装
置としてのハードディスク装置１００６、フロッピーデ
ィスク装置１００７および光ディスク装置１００８をバ
ス１００９により接続して構成されている。

【００６５】ここで、ハードディスク装置１００６、フ
ロッピーディスク装置１００７および光ディスク装置１
００８のいずれかの記録媒体に上述した実施形態で説明
した図７に示したユーザアプリケーション１のデバッグ
処理を実行するためのプログラムが格納される。このプ
ログラムに記述された処理は、図１のソフトウエア開発
支援装置３の各部で実行される処理と同様で、本発明の
ソフトウエア開発支援方法を実現するためのプログラム
であり、その詳細は、前述したとおりである。また、デ
バッグ対象のユーザアプリケーション１もハードディス
ク装置１００６、フロッピーディスク装置１００７およ
び光ディスク装置１００８のいずれかの記録媒体に格納
される。マルチタスクＯＳ２は、ＲＡＭ１００５に格納
されている。そして、ＣＰＵ１００１１の制御のもと、
記録媒体からデバッグ処理を実行するためのプログラム
を読み取りながら、このプログラムに従って、マルチタ
スクＯＳ２の管理下でユーザアプリケーション１のデバ
ッグを実行することになる。このようにして、通常のパ
ーソナルコンピュータを用いて本発明のソフトウエア開
発支援方法を実施することができる。 （ｅ）効果 以上説明したように、上記実施形態によれば、ブレーク
パターン入力部８からマルチタスクＯＳ２上で実行され
るユーザアプリケーション１のタスクの禁止動作の条件
が入力されると、それに基づき、ブレークパターン生成
部１２ではタスクの状態遷移に基づくブレークパターン
を生成する。ＯＳ内部状態読取部１３は、ユーザアプリ
ケーション１の実行開始時にマルチタスクＯＳの内部状
態（例えば、ユーザアプリケーション１のタスク制御ブ
ロック、セマフォ制御テーブルの内容）を読み出して、
ＯＳ状態テーブル１６に初期値として記録し、イベント
読取部１４は、ユーザアプリケーション１実行中に発生
したタスクの状態を遷移させるイベントをマルチタスク
ＯＳ２から読み出してブレーク状態検出部１５に通知
し、ブレーク状態検出部１５は、その通知されたイベン
トに基づきＯＳ状態テーブル１６の内容を更新するとと
もに、その通知されたイベントとブレークパターン生成
部１２で生成されたブレークパターンとに基づきユーザ
アプリケーション１ののタスクのブレーク状態を検出す
る。ブレーク状態を検出すると、ＯＳ制御部１７を介し
てユーザアプリケーション１の実行の中断マルチタスク
ＯＳ２に指示し、そのときのＯＳ内部状態テーブル１６
の内容を出力する。なお、ユーザアプリケーション１の
実行を再開する際には、再び、ＯＳ内部状態読取部１３
がマルチタスクＯＳの内部状態を読み取って、ＯＳ内部
状態テーブル１６の初期値として記録する。従って、ユ
ーザアプリケーションの実行中断（ブレーク）ポイント
の設定および誤動作ポイントの検出、さらに誤動作検出
時のＯＳ内部状態の参照が容易に行え、デバッグ作業の
負担が軽減できる。

【００６６】また、ブレークパターンライブラリに格納
されたブレークパターンの雛形とユーザの所望のブレー
ク条件に基づき、デバック対象のユーザアプリケーショ
ンのブレーク状態を検出するためのブレークパターンを
生成することにより、ユーザアプリケーションのバグ発
生箇所が容易に検出でき、デバッグ作業の負担が軽減で
きる。

【００６７】また、ＯＳ状態テーブル１６には、ＯＳ内
部状態読取部１３で読み取られたマルチタスクＯＳ２内
にあるＯＳ内部状態を記憶し、その記憶された内容をＯ
Ｓブレーク状態検出部１５で、イベント読取手段から読
み取ったイベントに基づいて更新するようになっている
ので、ＯＳ状態テーブル１６には常に最新のＯＳ内部状
態がコピーされることになり、マルチタスクＯＳ２内の
ＯＳ内部状態の情報が必要になった時は、ＯＳ状態テー
ブル１６の情報を参照すればよく、マルチタスクＯＳ２
とのデータの授受は、マルチタスクＯＳ２内メモリの読
み出をする必要がなくなりデバッグ処理が高速化され
る。

【００６８】イベント読取部１４が、マルチタスクＯＳ
２から読み取ったＯＳ内部イベントをイベント履歴情報
としてファイルに格納することと、イベント履歴情報か
らＯＳ内部イベントを再生できるように構成されている
ため、実際にユーザアプリケーションを実行したときの
ＯＳ内部イベントの発生状況をデバッグ時に再現するこ
とができる。

【００６９】さらに、ブレークパターンが、状態遷移図
によって表現されるように構成されているため、他の表
現方式、例えばツリー構造などによる表現法式に比べ
て、ブレーク状態検出部１５の内部構造が単純化でき、
条件判定処理のオーバーヘッドを少なくできる。

【００７０】

【発明の効果】以上説明したように、本発明によれば、
ＯＳ上で実行されるソフトウエアの実行中断（ブレー
ク）ポイントの設定および誤動作ポイントの検出、さら
に誤動作検出時のＯＳ内部状態の参照が容易に行え、デ
バッグ作業の負担が軽減できる。

【図面の簡単な説明】

【図１】本発明の一実施形態に係るソフトウエア開発支
援装置の構成例と、そのソフトウエア開発支援装置を用
いて、ＯＳ（マルチタスクＯＳ）上で実行されるユーザ
アプリケーションのデバッグを行う場合の全体の構成を
概略的に示した図。

【図２】ＯＳ内部状態の記憶例を示した図。

【図３】マルチタスクＯＳのタスク制御ブロックの構造
を示す図。

【図４】マルチタスクＯＳのセマフォ制御テーブルの構
造を示す図。

【図５】ユーザアプリケーションの構成例を示した図。

【図６】ユーザアプリケーションの動作の一例を示した
タイミングチャート。

【図７】ソフトウエア開発支援装置の動作を説明するた
めのフローチャート。

【図８】第１のブレークパターンの雛形の具体例を示し
た図。

【図９】第２のブレークパターンの雛形の具体例を示し
た図。

【図１０】ブレークパターン情報の具体例を示した図。

【図１１】ユーザアプリケーション全体に関するアプリ
ケーション情報の具体例を示した図。

【図１２】タスクに関するアプリケーション情報の具体
例を示した図。

【図１３】セマフォに関するアプリケーション情報の具
体例を示した図。

【図１４】第１の制約条件（ブレークパターン情報）と
図８のブレークパターンの雛形に基づき生成されたブレ
ークパターンの具体例を示した図。

【図１５】第２の制約条件（ブレークパターン情報）と
図９のブレークパターンの雛形に基づき生成されたブレ
ークパターンの具体例を示した図。

【図１６】ユーザアプリケーションを実行した際に発生
するＯＳ内部状態の履歴の一例を示した図。

【図１７】イベントＩＤの意味とイベント引数を記憶す
るテーブルの一例を示した図。

【図１８】システムコール発行イベントの引数の数と内
容を記憶するテーブルの一例を示した図。

【図１９】トレース情報出力部のユーザインタフェース
の表示例を示した図。

【図２０】図７に示した本発明に係るＯＳの下で実行さ
れるユーザアプリケーションのデバッグに用いるソフト
ウエア開発支援方法を実現するコンピュータシステムの
構成を示した図。

【符号の説明】

１…ユーザアプリケーション ２…マルチタスクＯＳ ３…ソフトウエア開発支援装置 ８…ブレークパターン入力部 ９…アプリケーション情報記憶部 １０…ブレークライブラリ記憶部 １１…ブレークパターン記憶部 １２…ブレークパターン生成部 １３…ＯＳ内部状態読取部 １４…イベント読取部 １５…ブレーク状態検出部 １６…ＯＳ状態テーブル記憶部 １７…ＯＳ制御部 １８…トレース情報出力部 １９…イベント履歴情報記憶部 ２０…ブレーク情報出力部

Claims (3)

【特許請求の範囲】
1. 【請求項１】 システムで実行されるソフトウエアのタ
   スクの状態遷移に基づく前記タスクの禁止動作のパター
   ンを生成し、前記ソフトウエアの実行の際に前記ソフト
   ウエア実行に基づき発生するイベントに従って遷移させ
   たタスクの状態と前記生成されたパターンとに基づい
   て、前記ソフトウエアのタスクの禁止動作を検出したと
   き、前記ソフトウエアの実行の中断を指示することを特
   徴とするソフトウエア開発支援方法。
2. 【請求項２】 システムで実行されるソフトウエアのタ
   スクの状態遷移に基づく前記タスクの禁止動作の条件を
   入力する入力手段と、 この入力手段で入力された条件に基づき前記ソフトウエ
   アのタスクの状態遷移に基づく前記タスクの禁止動作の
   パターンを生成する生成手段と、 前記ソフトウエアの実行の際に前記ソフトウエア実行に
   基づき発生するイベントに従って遷移させたタスクの状
   態と前記生成されたパターンとに基づいて、前記ソフト
   ウエアのタスクの禁止動作を検出する検出手段と、 この検出手段で禁止動作が検出されたとき、前記ソフト
   ウエアの実行の中断を指示する指示手段と、 を具備したことを特徴とするソフトウエア開発支援装
   置。
3. 【請求項３】 システムで実行されるソフトウエアの誤
   動作を検出するためのプログラムを記録した機械読み取
   り可能な記録媒体であって、 システムで実行されるソフトウエアのタスクの状態遷移
   に基づく前記タスクの禁止動作のパターンを生成する生
   成手段と、 前記ソフトウエアの実行の際に前記ソフトウエア実行に
   基づき発生するイベントに従って遷移させたタスクの状
   態と前記生成されたブレークパターンとに基づいて、前
   記ソフトウエアのタスクの禁止動作を検出する検出手段
   と、 この検出手段で禁止動作が検出されたとき、前記ソフト
   ウエアの実行の中断を指示する指示手段と、 を実行するプログラムを記録した記録媒体。