JP4208460B2 - ソフトウエアシステム動作確認装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は工学的開発方法論に則ったモデル分析を行い、そのモデルからソフトウエアコードに変換されたプログラム（ソフトウエアモデル）の実行に際して、その実行状態を記録、出力表示すると共に、元となったソフトウエアモデルを出力表示させる方法ならびに装置のソフトウエアシステム動作確認装置に関するものである。
【０００２】
【従来の技術】
従来、ソフトウエアの保守とメンテナンス、あるいは開発時の動作確認やデバッグのために、ファンクションモジュールの呼び出しやイベント送受信や、その際の各変数の値など、プログラムの実行状態を実行ログとして記録する事が行われてきた。
【０００３】
特に最近では、工学的開発方法論であるオブジェクト指向開発が取り入れられて来た事により、プログラム構造をオブジェクトモデル図（以下モデル図）という可視化された図面によって、一層開発者が把握し易くなってきており、実行ログとプログラム論理との対応付けが容易となり、その保守効率が向上されてきた。その場合の記録内容としては、インスタンス名、イベント名、状態名、属性値と、その他時刻などの付加情報が挙げられる。
【０００４】
【発明が解決しようとする課題】
ところが、オブジェクトモデル図によってプログラムの論理が可視化された事により、その実行状態をトレースする事自体は容易になってはいるが、しかし、一般的にモデル図は分析を記したものであり、「タスク」といった実装／設計に依存する情報までは表現されないものである。
【０００５】
モデル上のオブジェクト（のインスタンス）が、どのタスクに属するのかは把握できていても、前記プログラム実行ログとタスクスイッチ状態を相関して表現するのは容易ではないため、マルチタスク環境下での実行ログのトレースにはコツを要していた。特に、処理途中のタスクスイッチ（プリエンプション）により、処理を中断されたタスク側と、新たに処理を行うタスク側で、たまたま同一のデータを更新する事になるような場合、その更新タイミングによって思わぬ計算違いを起こしてプログラムが正しく動作しなくなるような状況が生じる場合がある。そのような問題を避けるために、そのデータの一貫性を保証する必要があるのだが、それと同時に、その状況を記録し検証することが可能な環境が望まれている。記録と検証のための環境として、処理実行された状況について、その時のデータ更新状態、ならびに、プリエンプション発生状況などのタスク状態についての情報一覧を、開発者が容易に読み取れる仕組みが必要となっている。
【０００６】
さらに、モデルすなわちプログラムのバージョンが複数存在するような場合に、ある装置にインストールされているバージョンがどのような機能をもったものか特定するためには、バージョン番号から過去のプログラム履歴を照合し、その機能について資料を辿る必要があり、その作業は煩雑なものであった。
【０００７】
本発明は、以上に点に着目して成されたもので、モデル図とそれに対応されたタスク情報を相関してプログラムの実行履歴として記録し、読み出す事を可能とすると同時に、プログラムの元となったモデルを確認することができることによって、複数の異なるバージョンが存在する場合にでも、適切にプログラムの保守やメンテナンス、あるいは開発時の動作確認やデバッグを、より容易で効率的に行えるソフトウエアシステム動作確認装置を提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記課題を解決するために、本発明によれば、ソフトウエアシステム動作確認装置に、工学的開発方法論に基づいて作成されたモデルを記憶するモデル記憶手段と、前記モデル記憶手段に記憶されたモデルをコードに変換したプログラムをマルチタスク環境下にて動作実行するプログラム実行手段と、前記プログラム実行手段によるプログラム実行ログとして、受信されたイベントに対して、そのイベントを受信したタスクと、そのタスクを実行するオブジェクトのインスタンスと、そのイベントをトリガとして状態遷移したオブジェクトの状態と、その状態の振る舞いにより更新された属性の値と、そのイベントの処理中にプリエンプションが発生したか否かを示す情報とを、逐次記録していくプログラム実行ログ記録手段と、前記プログラム実行ログ記録手段に記録されたプログラム実行ログを読み出すプログラム実行ログ読み出し手段と、前記プログラム実行ログ読み出し手段により読み出されたプログラム実行ログを、複数のイベントについてイベント毎に１行で表現した表形式により出力するプログラム実行ログ出力手段とを備える。
【００２１】
【発明の実施の形態】
図１０は、本プログラムが動作する装置を説明するものである。
【００２２】
ＣＰＵ２０１は画像形成装置全体の制御をつかさどるマイクロプロセッサーで、マルチタスク・リアルタイムＯＳによって動作をしている。
【００２３】
ＨＤＤ２０２は前記ＣＰＵ２０１が動作を行う上での複数のアプリケーションを蓄積しておく大容量ハードディスクであり、本件におけるシステム分析を行ったモデル図の情報や、そのプログラム実行状態記録情報などが含まれる。前述のＣＰＵ２０１の管理下にあるものである。
【００２４】
メモリ２０３はＣＰＵ２０１が動作する上でのワークメモリであり、ＨＤＤ２０２と同じく本件におけるシステム分析を行ったモデル図の情報や、そのプログラム実行状態記録情報などが含まれる。ＣＰＵ２０１から高速にアクセスできるものである。
【００２５】
高速ＣＰＵバス２０４は前述したＣＰＵ２０１、ＨＤＤ２０２、メモリ２０３や、後述する各機能ユニットとを接続するバスで、ＣＰＵ２０１が処理したデータを各機能ユニットに転送したり、各機能ユニット間同士でデータを高速に転送（ＤＭＡ転送）するためのものである。一般的にはＶＬバス又はＰＣＩバスがあげられる。
【００２６】
ＲＩＰ２０５は後述するコンピュータと接続される外部インターフェースより入力された、画像形成コマンドを受け、その内容に従ってビットマップ画像に変換を行う機能ユニットであると同時に、メモリ２０３またはＨＤＤ２０２上に存在するプログラム実行状態記録情報を受け、その内容に従ってビットマップ画像に変換を行う機能ユニットである。画像形成コマンドは高速ＣＰＵバス２０４より入力され、後述する高速イメージバス２１６にイメージ画像を出力するものである。ＲＩＰの種類としては、ポストスクリプト、ＰＣＬ、ＬＩＰＳ、ＣａＰＳＬ等があげられる。
【００２７】
画像処理２０６は、高速イメージバス２１６から入力されたイメージ画像をＣＰＵ２０１の指示による処理命令に従って、スムージング処理やエッジ処理などのイメージ画像に対するフィルタリング処置を行う機能ユニットである。
【００２８】
この他にも、画像処理２０６の機能としては、高速イメージバス２１６より入力された画像に対して文字認識（ＯＣＲ）機能や、文宇部とイメージ部を分離するイメージセパレート機能をも有する。
【００２９】
圧縮／伸長２０７は、高速イメージバス２１６から入力されたイメージ画像に対して、ＭＨ，ＭＲ，ＭＭＲ，ＪＰＥＧ等の画像圧縮方法により圧縮をかけ、高速ＣＰＵバス２０４又は、再び高速イメージバス２１６にその圧縮されたデータを送出したり、その逆にそれらの２つのバスから入力された圧縮データを、この機能ユニットにより圧縮された方式に従って伸長し、高速イメージバス２１６に送出する機能を持つものである。
【００３０】
バスブリッジ２０８は高速ＣＰＵバス２０４と後述する低速ＣＰＵバス２０９とをつなぐためのバスブリッジコントローラで、バス間の処理スピードの差を吸収するものである。このバスブリッジ２０８を介することで高速に動作するＣＰＵ２０１は低速ＣＰＵバス２０９に接続された低速に動作する機能ユニットをアクセスすることができる。
【００３１】
低速ＣＰＵバス２０９は、前記高速ＣＰＵバス２０４よりは転送速度の遅いバス構成で、処理能力の比較的遅い機能ユニットがつながるためのバスである。一般的にはＩＳＡバス等があげられる。
【００３２】
モデム２１０は、公衆回線２１１と低速ＣＰＵバス２０９とを介在する機能ユニットで、低速ＣＰＵバス２０９より送られてきたデジタルデータを公衆回線にデータを流せるように変調する機能と、公衆回線より送られてきた変調されたデータを画像形成装置内で処理できるデジタルデータに変換する機能を持つ。ＨＤＤ２０２またはメモリ２０３上に存在するプログラム実行状態記録情報を読み出す事が可能である。
【００３３】
ＬＡＮ２１３は、本画像形成装置を構内ネットワークに接続するための機能ユニットで、構内ネットワークとのデータの送受信を行うためのものである。一般的には、イーサネット（Ｒ）等があげられる。ＨＤＤ２０２またはメモリ２０３上に存在するプログラム実行状態記録情報を読み出す事が可能である。
【００３４】
管理装置インターフェース２１４は、本画像形成装置と管理装置とを接続するための機能ユニットで、本インターフェース２１４を介して、管理装置へ本画像形成装置から制御コマンドを送ったり、管理装置から本画像形成装置ヘイネーブル信号を返したりするのに使用される機能ユニットである。ＨＤＤ２０２またはメモリ２０３上に存在するプログラム実行状態記録情報を読み出す事が可能である。
【００３５】
パネルインターフェース２１５は、画像形成装置における操作部２２１との各種制御信号をやりとりするところで、後述する操作部２２１に配置されているキー等の入力スイッチの信号をＣＰＵ２０１に伝えたり、ＲＩＰ２０５、画像処理部２０６、圧縮／伸長部２０７で作成された画像データを操作部２２１にある液晶表示部に表示するための解像度変換を行うユニットである。ＨＤＤ２０２またはメモリ２０３上に存在するプログラム実行状態記録情報を読み出す事が可能である。
【００３６】
高速イメージバス２１６は各種画像生成ユニット（ＲＩＰ２０５、画像処理２０６、圧縮／伸長２０７）における画像入出力バスと後述するスキャナインターフェース２１７、プリンタインターフェース２１９とを相互に接続するためのバスである。このバスの制御はＣＰＵ２０１の管理下にはおかれず、後述するバスコントローラによって制御されデータ転送を行う。
【００３７】
スキャナユニット２１８は原稿自動送り装置を備えた可視画像読みとり装置で、ＲＧＢの３ラインのＣＣＤカラーセンサーまたは、１ラインの白黒のＣＣＤラインセンサーを有するものである。このスキャナユニット２１８で読みとられた画像データは、スキャナインターフェースユニット２１７によって、高速イメージバス２１６に転送される。
【００３８】
スキャナインターフェースユニット２１７においては、前記スキャナユニット２１８で読みとられた画像データを、その後の過程における処理の内容によって、最適な２値化を行い、高速イメージバス２１６のデータ幅にあわせたシリアル−パラレル変換を行ったり、読み込まれたＲＧＢの３原色のカラーデータをＣＭＹＢｋのデータに変換したりする機能を持ち合わせる。
【００３９】
プリンタユニット２２０は、後述するプリンタインターフェースユニット２１９から受け取った画像データを、記録用紙上に可視画像データとして印刷するものである。読み出したプログラム実行状態記録情報結果を出力印刷するものである。プリンタユニット２２０には、バブルジェット（Ｒ）方式を用いて記録用紙上に印刷するバブルジェット（Ｒ）プリンタや、レーザ光線を利用して感光ドラム上に画像を形成し記録用紙に画像を形成する電子写真技術を利用したレーザビームプリンタがあげられる。レーザビームプリンタには単色のものと、ＣＭＹＢｋによるカラーレーザビームプリンタがある。
【００４０】
プリンタインターフェースユニット２１９は高速イメージバス２１６から送られてきた画像データをプリンタユニットに転送するもので、高速イメージバス２１６のバス幅から出力しようとするプリンタの階調にあわせたバス幅に変換するバス幅変換機能や、プリンタの印刷速度と高速イメージバス２１６の画像データの転送速度の差を吸収するための機能を有する。
【００４１】
操作部２２１は液晶表示部と液晶表示部上に張り付けられたタッチパネル入力装置と、複数個のハードキーを有する。タッチパネルまたはハードキーにより入力された信号は前述したパネルインターフェース２１５を介してＣＰＵ２０１に伝えられ、液晶表示部はパネルインターフェース２１５から送られてきた画像データを表示するものである。液晶表示部には、本画像形成装置の操作における機能表示や画像データ等を表示する。読み出したプログラム実行状態記録情報結果を出力表示するものである。
【００４２】
次に、オブジェクト指向分析におけるモデル図について説明する。
【００４３】
工学的手法であるオブジェクト指向を用いた一般的なソフトウエア開発において、モデル図としてどのようなものを必要とするかは、各工学的手法、各方法論によってそれぞれ定められているが、一般的には情報モデル、状態モデルを列挙することができる。
【００４４】
オブジェクトとは、システムが対象とする実世界に存在する実体を抽象化したものであり、その中には、その抽象化された実体の識別を可能とする識別子と、その実体が持つ性質を抽象化した属性が含まれる。それぞれのオブジェクトは、実世界の中で体系的に成立する関連の集合を抽象化した関係で結ばれている。これら定義されたオブジェクトと、その相互関係を定義し、システムの静的側面を表現したものが情報モデルである。
【００４５】
インスタンスとは、その抽象化したオブジェクトの実体そのものである。例えばある人が保有している２台の自動車を抽象化してオブジェクトとした場合、自動車というオブジェクトは１つだが、実際に存在する１号車、２号車それぞれが別々なインスタンスとなる。
【００４６】
前記情報モデルから、それぞれのオブジェクトの動作側面を表したものが状態モデルである。オブジェクトの状態遷移（ライフサイクルとも言う）を定め、それぞれの状態での動的な振る舞いを記述していく。それぞれの状態はイベントによって遷移され、それぞれの状態がオブジェクトの行う処理の単位である。
【００４７】
次に、ソフトウエア開発にて作成されたモデル図について説明する。
【００４８】
まず、情報モデルについて図１を用いて説明する。
【００４９】
オブジェクトＯｂｊ１は、その識別子をｏｂｊ＿ＩＤとし、ａという属性を持っている。同じく、オブジェクトＯｂｊ２は、その識別子をｏｂｊ２＿ＩＤとし、ｚという属性を持っている。両オブジェクトは関係Ｒ１によって関係付けられており、その対応は１対１である。つまり、Ｏｂｊ１のインスタンスは必ず１つのＯｂｊ２のインスタンスと関係し、その反対に、Ｏｂｊ２のインスタンスは必ず１つのＯｂｊ１のインスタンスと関係すると記されている。
【００５０】
次に、Ｏｂｊ１の状態モデルについて図２を用いて説明する。
【００５１】
状態としてはＳｔａｔｅ１とＳｔａｔｅ２が定義されており、オブジェクトはそのいづれかの状態をとるという事がわかる。それぞれの状態遷移のトリガとして、ｉｎｉｔ，ｎｅｘｔ，ｂａｃｋのイベントが定義されている。プログラム立ち上げ時の初期状態位置は、その数字の小さい方、すなわちＳｔａｔｅ１であり、ｎｅｘｔイベントを受ける事により、Ｓｔａｔｅ２の振る舞いを実行する事になる。各状態遷移を起こす有効なイベント以外のイベントは無視される事になる。
【００５２】
例えばＳｔａｔｅ１の状態である場合に、ｂａｃｋイベントを受信しても無視され、何の振る舞いも実行されない。ｉｎｉｔイベントは、Ｓｔａｔｅ１の状態で受け取る限り、Ｓｔａｔｅ１の振る舞いを実行する事になる。特にｉｎｉｔイベントは、プログラムの立ち上げ時にその初期化処理の終了とともに、外部処理部であるＢｏｏｔモジュールから１回だけ送信される特別なイベントである。
【００５３】
次に、Ｓｔａｔｅ１の状態での振る舞いとして、ｐｏｓｔ（Ｓｅｌｆ：ｎｅｘｔ）と記されている。これは、ｎｅｘｔというイベントを、Ｓｅｌｆ、つまり自インスタンスヘ送信している意である。また、Ｓｔａｔｅ２の状態での振る舞いとしては、Ｓｅｌｆ［ａ］＝ｆｕｎｃ１（Ｓｅｌｆ［ａ］）にて、ｆｕｎｃ１という関数を呼び出している。その引数としてＳｅｌｆ［ａ］、つまり、自インスタンスの属性ａの値を渡し、同じくその返値を改めて自インスタンスの属性ａに代入している。
【００５４】
次に、ｐｏｓｔ（Ｓｅｌｆ：ｂａｃｋ）によって、ｂａｃｋというイベントを、Ｓｅｌｆ、つまり自インスタンスヘ送信している。これにより、現在の状態Ｓｔａｔｅ２からＳｔａｔｅ１への状態遷移を行わせている。
【００５５】
次に、Ｏｂｊ２の状態モデルについて図３を用いて説明する。
【００５６】
状態としてはＳｔａｔｅ１が定義されている。取り得る状態はただ１つであるが、その振る舞いを呼び出すイベントとしてｏｎが定義されている。ｏｎイベントを受け取る度に、Ｓｔａｔｅ１の振る舞いを実行する事になる。Ｓｔａｔｅ１の振る舞いとしては、Ｓｅｌｆ［ｚ］＝ｆｕｎｃ２（Ｓｅｌｆ［ｚ］）にて、ｆｕｎｃ２という関数を呼び出している。その引数としてＳｅｌｆ［ｚ］、つまり、自インスタンスの属性ｚの値を渡し、同じくその返値を改めて自インスタンスの属性ｚに代入するものである。
【００５７】
ここで、状態から呼び出される関数ｆｕｎｃ１について図４を用いて説明する。
【００５８】
ｆｕｎｃ１はプログラム言語を用いてコーディングされたソースコードである。引数ａをインクリメントした結果を返す。
【００５９】
同じく関数ｆｕｎｃ２について図５を用いて説明する。
【００６０】
ｆｕｎｃ２はプログラム言語を用いてコーディングされたソースコードである。引数ｚを２倍した結果を返す。
【００６１】
さて、ここで、Ｏｂｊ１とＯｂｊ２の実行が、それぞれ別々のタスクＴａｓｋ１とＴａｓｋ２として実装する場合を考える。より正確にいえば、Ｏｂｊ１のインスタンスはＴａｓｋ１として実行され、Ｏｂｊ２のインスタンスはＴａｓｋ２として実行される事になる。以降、それぞれのオブジェクトが１つのインスタンスをそれぞれ持つ場合を考える。
【００６２】
タスクの実行状態を図６を用いて説明する。
【００６３】
Ｔａｓｋ１にはＯｂｊ１のインスタンスが属す。そのインスタンスはＳｔａｔｅ１とＳｔａｔｅ２の状態のどちらかをとる。Ｔａｓｋ２にはＯｂｊ２のインスタンスが属し、取り得る状態はＳｔａｔｅ１のみである。実行されている期間は太線で表現されている。先端の黒丸印は、その状態が始まった箇所（それ以前の状態から遷移を起こす箇所）を意味し、次の黒丸印の箇所までは状態遷移が発生していない事を意味するものである。点線で表現されている部分は、本来ある処理を実行したいのだが、タスクの制限により他の処理が実行されているため、そのタスク自体が処理待ちとなっている期間を意味している。
【００６４】
太矢印はオブジェクトＯｂｊ１，Ｏｂｊ２以外の外的要因から送られてくるイベントを受信するタイミングを表現している。細矢印はオブジェクトＯｂｊ１，Ｏｂｊ２の振る舞いとして発せられたイベントを意味しており、実際にそのイベントが受信されたタイミング箇所に記されている。前記イベントが送信されたタイミングは☆印で表現されており、注釈線にてそのイベントが送られた状態モデルでの振る舞い記述が参考までに記されている。
【００６５】
ここで、ある一方のオブジェクトの状態の振る舞い処理を実行している最中にはタスクスイッチを起こさない、つまり状態の切れ目でのみタスクスイッチを許可するという場合を例にする。これは、オブジェクト間でプリエンプションを行わない、というように表現する事もできる。図６を用いて詳細に説明する。
【００６６】
タスク優先順位は、Ｔａｓｋ１よりもＴａｓｋ２の方が高い（Ｔａｓｋ１＜Ｔａｓｋ２）とする。
【００６７】
※１にて、Ｂｏｏｔモジュールよりｉｎｉｔイベントを受け取る。これにより、以降、処理が進む事になる。Ｔａｓｋ１が実行状態となり、Ｓｔａｔｅ１の振る舞いを実行する。Ｔａｓｋ２は依然として処理を必要とせず休眠状態である。Ｓｔａｔｅ１の振る舞いの最後に自分に対してｎｅｘｔイベントを送信する。未処理イベントを判断し、他に実行を待っているタスクはないため、※２にて、Ｔａｓｋ１がそのままｎｅｘｔイベントを受信し、Ｓｔａｔｅ２の振る舞いを実行する。その実行途中に※３に示されるｏｎイベントがＴａｓｋ２に送信された場合、本来ならばタスク優先順位の高いＴａｓｋ２の処理を即座に実行したいところだが、ここではオブジェクト間でのプリエンプション不可として実装されているため、Ｔａｓｋ１の処理、つまり、Ｏｂｊ１のＳｔａｔｅ２の振る舞いの終了までＴａｓｋ２の実行は待たされる事になる。Ｏｂｊ１のＳｔａｔｅ２の振る舞いの最後に自分に対してｂａｃｋイベントを送信する。この時点で、Ｏｂｊ１に対してｂａｃｋイベントが、そして、Ｏｂｊ２に対してｏｎイベントがそれぞれ送られている。さて、Ｓｔａｔｅ２の振る舞いが終了したら、※４で示されるようにそのタスクの優先順位を判断し、高い優先順位を持つＴａｓｋ２の処理が実行される事になる。その後Ｔａｓｋ２の処理、すなわちＳｔａｔｅ１の振る舞い処理が終了した段階で、※５に示す通り改めて残されている未処理イベントを判断し、Ｔａｓｋ１のｂａｃｋイベントを処理する。これによりＴａｓｋ１が実行状態となり、Ｏｂｊ１の状態はＳｔａｔｅ１へと移り、該振る舞いを実行することになる。以降、一連の処理を続けていく。
【００６８】
この場合の動作実行ログの記録について図８を用いて説明する。
【００６９】
ログとして記録される情報は図８に示されるようなものであり、その記録内容として、受信したイベント、受信したタスク、受信したオブジェクト、受信したインスタンス、それにより実行された状態名、状態中で更新された属性の値、プリエンプションが発生したか否か、の各情報が記録される。
【００７０】
記録は、前述した図６の処理説明に対応して行われるものであり、イベントを受信してから、その状態が終了するまでの間の、その振る舞い実行による属性値の更新結果を１行に表現する。ここでは、Ｏｂｊ１のインスタンスは、識別子（ｏｂｊ＿ＩＤ）の値が１であるとし、Ｏｂｊ２のインスタンスは、識別子（ｏｂｊ２＿ＩＤ）の値が１０であるとする。属性値が更新されなかった場合には「−」表示となる。属性は図１で示されるとおり、Ｏｂｊ１ではａ，Ｏｂｊ２ではｚを指す。ここでは、それぞれ初期値は「１」であるものとしている。
【００７１】
プリエンプション欄で、「Ｎｏ」と記されているものは、実行状態の振る舞い処理が、途中タスクスイッチ、つまりプリエンプションされる事無く最後まで連続して処理する事ができた結果を意味するものである。この実行ログ結果を確認する事により、それぞれのモデルの実行状態を確認すると同時に、プリエンプション不可という実装通りにプリエンプションが発生していないかどうかを確認する事が可能となる。
【００７２】
（実施例２）
Ｏｂｊ１とＯｂｊ２の実行が、それぞれ別々のタスクＴａｓｋ１とＴａｓｋ２として実装する場合を考える。より正確にいえば、Ｏｂｊ１のインスタンスはＴａｓｋ１として実行され、Ｏｂｊ２のインスタンスはＴａｓｋ２として実行される事になる。以降、それぞれのオブジェクトが１つのインスタンスをそれぞれ持つ場合を考える。
【００７３】
タスクの実行状態を図７を用いて説明する。
【００７４】
Ｔａｓｋ１にはＯｂｊ１のインスタンスが属す。そのインスタンスはＳｔａｔｅ１とＳｔａｔｅ２の状態のどちらかをとる。Ｔａｓｋ２にはＯｂｊ２のインスタンスが属し、取り得る状態はＳｔａｔｅ１のみである。実行されている期間は太線で表現されている。先端の黒丸印は、その状態が始まった箇所（それ以前の状態から遷移を起こす箇所）を意味し、次の黒丸印の箇所までは状態遷移が発生していない事を意味するものである。点線で表現されている部分は、本来ある処理を実行したいのだが、タスクの制限により他の処理が実行されているため、そのタスク自体が処理待ちとなっている期間を意味している。
【００７５】
太矢印はオブジェクトＯｂｊ１，Ｏｂｊ２以外の外的要因から送られてくるイベントを受信するタイミングを表現している。細矢印はオブジェクトＯｂｊ１，Ｏｂｊ２の振る舞いとして発せられたイベントを意味しており、実際にそのイベントが受信されたタイミング箇所に記されている。前記イベントが送信されたタイミングは☆印で表現されており、注釈線にてそのイベントが送られた状態モデルでの振る舞い記述が参考までに記されている。
【００７６】
ここで、ある一方のオブジェクトの状態の振る舞い処理を実行している最中でも、それよりも優先順位の高いタスクを実行する必要が生じた場合には瞬時にタスクスイッチを起こす、つまり状態の切れ目以外でもタスクスイッチを許可するという場合を例にする。これは、オブジェクト間でプリエンプションを行う、というように表現する事もできる。図７を用いて詳細に説明する。
【００７７】
タスク優先順位は、Ｔａｓｋ１よりもＴａｓｋ２の方が高い（Ｔａｓｋ１＜Ｔａｓｋ２）とする。
【００７８】
※１にて、Ｂｏｏｔモジュールよりｉｎｉｔイベントを受け取る。これにより、以降、処理が進む事になる。Ｔａｓｋ１が実行状態となり、Ｓｔａｔｅ１の振る舞いを実行する。Ｔａｓｋ２は依然として処理を必要とせず休眠状態である。Ｓｔａｔｅ１の振る舞いの最後に自分に対してｎｅｘｔイベントを送信する。未処理イベントを判断し、他に実行を待っているタスクはないため、※２にて、Ｔａｓｋ１がそのままｎｅｘｔイベントを受信し、Ｓｔａｔｅ２の振る舞いを実行する。その実行途中に※３に示されるｏｎイベントがＴａｓｋ２に送信された場合、タスク優先順位の高いＴａｓｋ２の処理を即座に実行する事になる。ここではオブジェクト間でのプリエンプションを可として実装されているため、Ｔａｓｋ１の処理、つまり、Ｏｂｊ１のＳｔａｔｅ２の振る舞いは、その処理途中ではあるが一旦停止され、Ｔａｓｋ２の実行へと移る事になる。
【００７９】
※４にてＴａｓｋ２の振る舞い処理が終了した段階で、待たされていたＴａｓｋ１の処理、つまりＯｂｊ１のＳｔａｔｅ２の振る舞いの残り箇所が実行される事になる。振る舞いの最後に自分に対してｂａｃｋイベントを送信し、Ｓｔａｔｅ２の振る舞い処理が終了となる。
【００８０】
続いて、※５に示す通り改めて残されている未処理イベントを判断し、Ｔａｓｋ１のｂａｃｋイベントを処理する。これによりＴａｓｋ１が実行状態となり、Ｏｂｊ１の状態はＳｔａｔｅ１へと移り、該振る舞いを実行することになる。以降、一連の処理を続けていく。
【００８１】
この場合の動作実行ログの記録について図９を用いて説明する。
【００８２】
ログとして記録される情報は図８に示されるようなものであり、その記録内容として、受信したイベント、受信したタスク、受信したオブジェクト、受信したインスタンス、それにより実行された状態名、状態中で更新された属性の値、プリエンプションが発生したか否か、の各情報が記録される。
【００８３】
記録は、前述した図６の処理説明に対応して行われるものであり、イベントを受信してから、その状態が終了するまでの間の、その振る舞い実行による属性値の更新結果を１行に表現する。ここでは、Ｏｂｊ１のインスタンスは、識別子（ｏｂｊ１＿ＩＤ）の値が１であるとし、Ｏｂｊ２のインスタンスは、識別子（ｏｂｊ２＿ＩＤ）の値が１０であるとする。属性値が更新されなかった場合には「−」表示となる。属性は図１で示されるとおり、Ｏｂｊ１ではａ，Ｏｂｊ２ではｚを指す。ここでは、それぞれ初期値は「１」であるものとしている。プリエンプション欄で、「Ｎｏ」と記されているものは、実行状態の振る舞い処理が、途中タスクスイッチ、つまりプリエンプションされる事無く最後まで連続して処理する事ができた結果を意味するものであり、「Ｙｅｓ」と記されているものは、その振る舞い処理の途中でタスクスイッチ、つまりプリエンプションが発生したということを意味するものである。その本質上、「Ｙｅｓ」となっている状態は、いづれ再開される事になる。それを表現するのは、受信イベントで「ｃｏｎｔｉｎｕｅ」と記される行である。ただし、ｃｏｎｔｉｎｕｅイベントは予約されているものとし、モデル図中では使用できないという前提である。
【００８４】
図中では、２行目にてＴａｓｋ１，Ｏｂｊ１，Ｓｔａｔｅ２の処理を実行している途中で、３行目の通り、Ｔａｓｋ２，Ｏｂｊ２，Ｓｔａｔｅ１へとプリエンプションが発生し、その処理終了後、４行目に記されているとおり、割り込まれたＴａｓｋ１，Ｏｂｊ１，Ｓｔａｔｅ２の処理が続行されている事が確認できる。この実行ログ結果を確認する事により、それぞれのモデルの実行状態と、プリエンプション状態を容易に確認する事が可能となる。
【００８５】
（実施例３）
記録された実行ログ結果を操作部２２１に出力表示する場合について図１１、図１２を用いて説明する。
【００８６】
図１１は本装置における操作部２２１での画面表示状態である。画面はグラフィッカルに構成され、メッセージ表示や各種ボタン表示がなされている。その中で、実行ログ表示ボタン１１−１を押下する事により、実行ログ表示画面へと切り替わる。モデル確認ボタン１１−２については、後述のモデルを確認する項にて説明する。
【００８７】
図１２は実行ログが表示されている状態を表す。画面内には、記録されているプログラム実行状態が１度に５行分表示される。ただし、ここでは全部で４行分の情報である例となっている。上スクロールボタン１２−１は、画面を上ヘスクロールするボタンであり、前の５行分を表示する事になる。上スクロールに値する情報がある場合には黒く有効表示となるが、図のように上スクロールに値しないような場合には、網掛け表示され、押されても何も機能しない。下スクロールボタン１２−３も同様である。ページ表示部１２−２は、総ページ数を分母に、現在表示ページを分子とするものであり、全体の情報量と、現在表示中の情報の位置を特定する事が可能なものである。閉じるボタン１２−４は本画面を閉じ、図１１の画面へ戻るものである。現ページ印刷ボタン１２−５は、現在表示中のページ（５行分）を用紙にプリントアウトするためのボタンである。全印刷ボタン１２−６は、記録されている全ての実行ログ情報を用紙にプリントアウトするためのボタンである。
【００８８】
（実施例４）
動作しているプログラムの元となっている、記憶されているモデルを操作部２２１に出力表示する場合について図１１、１３、１４、１５を用いて説明する。
【００８９】
図１１は本装置における操作部２２１での画面表示状態である。画面はグラフィッカルに構成され、メッセージ表示や各種ボタン表示がなされている。実行ログ表示ボタン１１−１を押下する場合の説明は、実行ログを表示確認する項にて前述したとおり。モデル確認ボタン１１−２を押下すると、モデル確認表示画面へ切り替わる。
【００９０】
図１３は情報モデルが表示されている状態であり、それと分かるよう、情報モデルタブ１３−１が反転表示されている。モデル確認ボタン１１−２を押下すると、情報モデル画面が最初に表示される。情報モデルはシステムに１つとは限らないが、ここでは１つである場合を例に示している。複数ある場合には、後述の状態モデルを特定する場合のように、プルダウンメニューから選択する事になる。その場合は、情報モデルタブ１３−１を押下する事によってプルダウンメニューの表示となる。１３−９は表示マットであり、モデルを表示するエリアである。表示エリアは限られている範囲なので、上下左右スクロールが可能である。
【００９１】
１３−３，１３−４，１３−７，１３−８は各スクロールボタンであり、押下するとその方向へ表示マットを移動し、モデルの全体を確認する事が可能となる。閉じるボタン１３−１０は本画面を閉じ、図１１の画面へ戻るものである。現モデル印刷ボタン１３−５は、現在表示マット１３−９上に表示中のモデルだけを用紙にプリントアウトするためのボタンである。全印刷ボタン１３−６は、記憶されている全てのモデルを用紙にプリントアウトするためのボタンである。状態モデルタブ１３−２を押下する事により、各オブジェクトの状態モデルをそれぞれ表示させる事が可能である。
【００９２】
状態モデルタブ１４−１を押下すると、図１４に示すとおり、表示する状態モデルを特定する事が可能となる。
【００９３】
システムの状態モデルがプルダウンメニュー表示されており、プルダウンメニュー１４−２を押下する事により、Ｏｂｊ１オブジェクトの状態モデルを表示する事ができる。プルダウンメニュー１４−３を押下する事により、Ｏｂｊ２オブジェクトの状態モデルを表示する事ができる。
【００９４】
プルダウンメニュー１４−２を押下してＯｂｊ１のオブジェクトの状態モデルを表示した結果が図１５である。
【００９５】
表示マット１５−１上では、先ほどまでの情報モデルに代わり、Ｏｂｊ１オブジェクトの状態モデルが表示されている。その表示状態を示すために、状態モデルタブ１５−２は反転表示され、更に、識別を容易にするため、表示しているオブジェクト名であるＯｂｊ１が表示されている。
【００９６】
プルダウンメニュー１４−３を押下してＯｂｊ２のオブジェクトの状態モデルを表示した結果が図１６である。
【００９７】
表示マット１６−１上では、先ほどまでの情報モデルに代わり、Ｏｂｊ２オブジェクトの状態モデルが表示されている。その表示状態を示すために、状態モデルタブ１６−２は反転表示され、更に、識別を容易にするため、表示しているオブジェクト名であるＯｂｊ２が表示されている。
【００９８】
【発明の効果】
以上説明したように、本発明によれば、プログラムが処理実行された状況について、その時のデータ更新状態、ならびに、プリエンプション発生状況などのタスク状態についての情報を一覧化して記録し、そしてそれを読み出し可能とする事で、開発者が容易にプログラムの動作確認を行うことができる。それにより、プログラムの保守やメンテナンス、あるいは開発時の動作確認やデバ
ッグを、より容易で効率的に行う事が可能となる。
【００９９】
さらに、モデルすなわちプログラムのバージョンが複数存在するような場合で、ある装置にインストールされているバージョンがどのような機能をもったものか特定する必要がある場合にも、装置内のプログラムの元となっているモデルを表示する事で有する機能を即座に判断する事ができ、その確認の手間を省く事ができる。
【図面の簡単な説明】
【図１】 システム分析による情報モデル図
【図２】 システム分析による状態モデル図
【図３】 システム分析による状態モデル図
【図４】 状態内で読み出される関数コード
【図５】 状態内で読み出される関数コード
【図６】 非プリエンプション時のタスク動作図
【図７】 プリエンプション時のタスク動作図
【図８】 非プリエンプション時の動作記録内容
【図９】 プリエンプション時の動作記録内容
【図１０】 装置の全体図
【図１１】 操作部表示画面図
【図１２】 操作部表示画面図
【図１３】 操作部表示画面図
【図１４】 操作部表示画面図
【図１５】 操作部表示画面図
【図１６】 操作部表示画面図
【符号の説明】
２０１ ＣＰＵ
２０２ ＨＤＤ
２０３ メモリ
２０４ 高速ＣＰＵバス
２０５ ＲＩＰ
２０６ 画像処理
２０７ 圧縮／伸長
２０８ バスブリッジ
２０９ 低速ＣＰＵバス
２１０ モデム
２１１ 公衆回線
２１３ ＬＡＮ
２１４ 管理装置インターフェース
２１５ パネルインターフェース
２１６ 高速イメージバス
２１７ スキャナインターフェース
２１８ スキャナユニット
２１９ プリンタインターフェース
２２０ プリンタユニット
２２１ 操作部
１１−１ 実行ログ表示ボタン
１１−２ モデル確認ボタン
１２−１ 上スクロールボタン
１２−２ ページ表示部
１２−３ 下スクロールボタン
１２−４ 閉じるボタン
１２−５ 現ページ印刷ボタン
１２−６ 全印刷ボタン
１３−１ 情報モデルタブ
１３−２ 状態モデルタブ
１３−３，１３−４，１３−７，１３−８ スクロールボタン
１３−５ 現モデル印刷ボタン
１３−６ 全印刷ボタン
１３−９ 表示マット
１３−１０ 閉じるボタン
１４−１ 状態モデルタブ
１４−２，１４−３ プルダウンメニュー
１５−１ 表示マット
１５−２ 状態モデルタブ
１６−１ 表示マット
１６−２ 状態モデルタブ

Claims (9)

1. 工学的開発方法論に基づいて作成されたモデルを記憶するモデル記憶手段と、
   前記モデル記憶手段に記憶されたモデルをコードに変換したプログラムをマルチタスク環境下にて動作実行するプログラム実行手段と、
   前記プログラム実行手段によるプログラム実行ログとして、受信されたイベントに対して、そのイベントを受信したタスクと、そのタスクを実行するオブジェクトのインスタンスと、そのイベントをトリガとして状態遷移したオブジェクトの状態と、その状態の振る舞いにより更新された属性の値と、そのイベントの処理中にプリエンプションが発生したか否かを示す情報とを、逐次記録していくプログラム実行ログ記録手段と、
   前記プログラム実行ログ記録手段に記録されたプログラム実行ログを読み出すプログラム実行ログ読み出し手段と、
   前記プログラム実行ログ読み出し手段により読み出されたプログラム実行ログを、複数のイベントについてイベント毎に１行で表現した表形式により出力するプログラム実行ログ出力手段とを有することを特徴とするソフトウエアシステム動作確認装置。
2. 前記プログラム実行ログ読み出し手段は、通信回線を介して外部の機器と通信を行うことを特徴とする請求項１に記載のソフトウエアシステム動作確認装置。
3. 前記モデル記憶手段に記憶された情報を読み出して出力するモデル読み出し手段を有することを特徴とする請求項１に記載のソフトウエアシステム動作確認装置。
4. 前記モデル読み出し手段は、通信回線を介して外部の機器と通信を行うことを特徴とする請求項３に記載のソフトウエアシステム動作破認装置。
5. ユーザとの情報交換を行うユーザインターフェース手段を有することを特徴とする請求項１に記載のソフトウエアシステム動作確認装置。
6. 前記プログラム実行ログ出力手段は、前記ユーザインターフェース手段を用いて出力表示を行うことを特徴とする請求項５に記載のソフトウエアシステム動作確認装置。
7. ユーザとの情報交換を行うユーザインターフェース手段を有し、前記モデル読み出し手段は、前記ユーザインターフェース手段を用いて出力表示を行うことを特徴とする請求項３に記載のソフトウエアシステム動作確認装置。
8. 前記モデル読み出し手段は、用紙媒体に印刷出力することを特徴とする請求項３に記載のソフトウエアシステム動作確認装置。
9. 前記プログラム実行状態出力手段は、用紙媒体に印刷出力することを特徴とする請求項１に記載のソフトウエアシステム動作確認装置。

Images