(57)【特許請求の範囲】
【請求項１】
複数のソフトウェア部品の結合により構成され、該複数のソフトウェア間の処理依頼の授受により機能するソフトウェアを検査するためのソフトウェア結合検査装置であって、
ソフトウェア部品間における処理依頼およびその出力条件としての処理データが文字および図形により時系列的に規定された設計書の画像表示データを格納する画像表示データ格納手段と、
該画像表示データ格納手段に記憶された画像表示データから、前記設計書上の文字及び図形の位置を検出し、該検出結果に基づいて、ソフトウェア部品間における処理依頼およびその処理データを設計書情報として読み取る設計書情報読取手段と、
前記設計書に基づき作成された前記ソフトウェアの実行結果を格納する実行結果格納手段と、
該実行結果格納手段に格納された実行結果から、該実行結果に格納されているソフトウェア部品間における処理依頼およびその出力条件としての処理データを実行履歴情報として時系列順に読み取る実行履歴情報読取手段と、
該実行履歴情報読取手段にて読み取られた実行履歴情報を、前記設計書情報読取手段にて読み取られた設計書情報と比較し、該両情報の一致・不一致を判定する比較判定手段と、
該比較判定による判定結果を、当該ソフトウェア結合検査装置外部に出力する出力手段と、
を備えたことを特徴とするソフトウェア結合検査装置。
【請求項２】
請求項１記載のソフトウェア結合検査装置において、
前記出力手段は、前記比較判定手段が前記実行履歴情報と前記設計書情報とが不一致であると判定すると、該実行履歴情報の内、前記設計書情報と不一致の箇所を出力することを特徴とするソフトウェア結合検査装置。
【請求項３】
請求項１又は２記載のソフトウェア結合検査装置において、
検査対象のソフトウェアは、所定の制御対象物を制御するための物理量をＡ／Ｄ変換して得られる制御データに基づき、該制御対象物を制御するためのものであって、
前記設計書には、前記処理データとして、前記制御対象物を制御するための物理量が記述されており、
前記Ａ／Ｄ変換により得られる制御データ毎に、そのＡ／Ｄ変換の際の分解能を表す分解能情報を記憶した分解能情報記憶手段を備え、
前記実行履歴情報読取手段は、前記実行結果格納手段に記憶された実行結果から、前記分解能情報に基づき、前記処理データとして、前記制御データを読み取ることを特徴とするソフトウェア結合検査装置。
【請求項４】
請求項３記載のソフトウェア結合検査装置において、
前記制御データ毎に、そのデータ型が符号付きか否かを表す符号情報を記憶した符号情報記憶手段を備え、
前記実行履歴情報読取手段は、前記実行結果格納手段に記憶された実行結果から、前記符号情報に基づき、前記制御データを読み取ることを特徴とするソフトウェア結合検査装置。
【請求項５】
請求項３又は４記載のソフトウェア結合検査装置において、
前記制御データ毎に、そのデータ長を表すデータ長情報を記憶したデータ長情報記憶手段を備え、
前記実行履歴情報読取手段は、前記実行結果格納手段に記憶された実行結果から、前記データ長情報に基づき、前記制御データを読み取ることを特徴とするソフトウェア結合検査装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、複数のソフトウェア部品（ソフトウェアモジュール）を結合することにより構成されるソフトウェアの結合検査を行うためのソフトウェア結合検査装置に関する。
【０００２】
【従来の技術】
従来より、例えばオブジェクト指向のシステム設計におけるソフトウェア開発では、複数のソフトウェア部品（オブジェクト指向では「オブジェクト」としてとらえられる）を結合することにより、所望の機能を有する新たなソフトウェアを開発することが行われている。なお、オブジェクト指向とは、人間が行動するときの如く操作対象に注目して仕事を進めるという考え方を、コンピュータシステムにモデル化したものであり、このオブジェクト指向のプログラミングでは、プログラムの処理を、オブジェクトという単位で考える。オブジェクトは、オブジェクト固有のデータとそのデータを扱う処理とを、一まとめにしたソフトウェアモジュールである。
【０００３】
オブジェクトの結合は、あるオブジェクトから別のオブジェクトに対し、特定の処理を実行して欲しい旨の「処理依頼（メッセージ）」が出力されることによって図られ、メッセージを受けたオブジェクトでは、そのメッセージにより特定される処理が行われる。従って、オブジェクトの結合により作成すべき新たなソフトウェアにて所望の機能を実現するためには、各オブジェクトからのメッセージの出力先、出力順序、出力条件等を設計（メッセージ・シーケンスの設計）することが必要となる。そしてメッセージ・シーケンスの設計には、例えば図８に示す様な、メッセージ・シーケンス・チャート（以下、「ＭＳＣ」という）という設計書が使用されることが多い。
【０００４】
図８はＭＳＣの一例を示す図であり、このＭＳＣでは、車両の自動変速装置の電子制御において、出力軸回転数に応じて自動変速機の変速段を１速から２速にシフトアップ（１−２変速）させる際に各オブジェクトが出力すべきメッセージが規定されている。このＭＳＣにおいて、「変速出力マネージャ」は、トルクコンバータの出力軸回転数に応じて変速段を決定するオブジェクトであり、「シーケンスマネージャ」は、例えば「現在変速中か否か」等の各種条件に基づいて変速可能か否かを判断するオブジェクトである。そして、「制御状態コントローラ」は、自動変速機内にある複数のソレノイドバルブの内、どのバルブをどのタイミングで開閉するかを決定するオブジェクトであり、「１−２変速制御部品」は、１−２変速に必要なソレノイドバルブの駆動制御を行うオブジェクトである。なお、「オブジェクトが…する。」や「オブジェクトは…する。」といったオブジェクトを主語とした動作表現は、実際には、コンピュータのＣＰＵがオブジェクトに従って動作する（換言すれば、ＣＰＵがオブジェクトとして規定された処理を実行する）ことで実現される機能手段が、上記「…」の動作を行うことを意味する。
【０００５】
そして、図８のＭＳＣでは、「変速出力マネージャ」は「出力軸回転数＝２００〜５００ｒｐｍ」と判断すると、「シーケンスマネージャ」に対して、１−２変速が可能か否かの判断処理を要求するメッセージ（１−２変速出力）を送ること、「シーケンスマネージャ」は、変速可能か否かの判断を行い、その結果、変速可能であるとき、変速種別を示す変速パターンＩＤを、１−２変速に当たる「０」に変更して、「制御状態コントローラ」に、１−２変速制御の処理を要求するメッセージ（１−２変速制御開始要求）を送ること、及び「制御状態コントローラ」は、ソレノイドバルプを決定し、決定されたソレノイドバルブを駆動するオブジェクトとしての「１−２変速制御部品」に通電処理を要求するメッセージ（通電開始要求）を送ることが、設計されている。
【０００６】
【発明が解決しようとする課題】
ところで、上記の様なＭＳＣに規定された結合を実現することを目標としてオブジェクトが作成（即ち、ソースプログラムが記述）されるが、その後、オブジェクト間の結合が設計通りに行われ、ソフトウェア全体として設計通りの機能が満足されるかどうかについての検査（所謂結合検査）が必要である。こうした結合検査は、ソースプログラムとＭＳＣを目で見て比較することにより実施することも考えられる。即ちＭＳＣに記述された順番通りに、メッセージ出力が行われているかどうかをソースプログラムを読んで追っていくことにより、両者が比較される。
【０００７】
しかし、それだけでは、実際に、その新たに開発したソフトウェアによってハードウェアを動作させた際に、ＭＳＣで規定されている機能・動作が実現されるかどうかを確かめることはできない。また、単に処理の実行順序を追うだけでは、上述の「出力軸回転数」や「変速パターンＩＤ」といった、マイクロコンピュータ内で扱われる処理データ（制御データ）についての所定条件（即ち、「出力軸回転数が２００ｒｐｍ以上５００ｒｐｍ以下」、「変速パターンＩＤが０」）が満たされた上で、「１−２変速出力」、「１−２変速制御開始要求」といったメッセージが出力されているかどうかを確かめることはできない。
【０００８】
例えば図８のＭＳＣにおいては、変速出力マネージャは「出力軸回転数が２００〜５００ｒｐｍ」であると判断すると、シーケンスマネージャに対して１−２変速を要求するメッセージを出力することが規定されているが、オブジェクト間におけるメッセージの流れのみを検査したのでは、実際の出力軸回転数が１０００ｒｐｍであるにも拘わらずメッセージが出力（発行）されてはいないか、などを検査することはできない。即ち、実際の出力軸回転数が１０００ｒｐｍであるにも拘わらず、１−２変速を要求するメッセージが出力されていたとしても、その誤りを発見することができない。
【０００９】
なお、こうした問題は、オブジェクト指向のシステム設計におけるソフトウェア開発に限られるものではなく、複数のソフトウェア部品の結合により新たなソフトウェアを作成する場合であれば、同様な問題が生ずる。
本発明は、上記問題に鑑みなされたものであり、複数のソフトウェア部品を結合して構成されるソフトウェアの結合検査を効率良く行うことができるソフトウェア結合検査装置を提供することを目的とする。
【００１０】
【課題を解決するための手段及び発明の効果】
上記課題を解決するためになされた本発明（請求項１記載）のソフトウェア結合検査装置においては、設計書情報読取手段が、画像表示データから、設計書上の文字及び図形の位置を検出し、その検出結果に基づいて、ソフトウェア部品間における処理依頼およびその処理データを設計書情報として読み取り、実行履歴情報読取手段が、設計書に基づき作成されたソフトウェアの実行結果から、該実行結果に格納されているソフトウェア部品間における処理依頼およびその出力条件としての処理データを実行履歴情報として時系列順に読み取り、比較手段が実行履歴情報と設計書情報とを比較して、その両情報の一致・不一致を判定し、出力手段が、その判定結果を当該ソフトウェア結合検査装置外部に出力する。
【００１１】
即ち、請求項１のソフトウェア結合検査装置においては、設計書の画像表示データから設計書情報（即ち設計書中に規定されているソフトウェア部品間における処理依頼およびその出力条件としての処理データ）を読み取り、一方、実行結果から実行履歴情報（即ち、ソフトウェア部品間における処理依頼およびその出力条件としての処理データ）を読み取り、その設計書情報と実行履歴情報とを比較し、両情報の一致・不一致を判定して、その判定結果を出力する。なお、両情報の比較とは、設計書情報に規定されている処理依頼と実行履歴情報内の処理依頼との比較、および、設計書情報に規定されている処理データと実行履歴情報内の処理データとの比較により図られる。
【００１２】
そのため、請求項１記載のソフトウェア結合検査装置によれば、複数のソフトウェア部品を結合して作成したソフトウェアによって設計書通りの処理動作が実現されているか否かを容易に判断することができる。しかも、両情報の比較は、ソフトウェア部品間における処理依頼だけでなく、処理依頼の出力条件についても行うので、正しい条件で他のソフトウェア部品に処理依頼されているかなど、ソフトウェア部品の結合の良否判断をより確実に行うことができる。なお、設計書情報と実行履歴情報とが「一致している」とは、設計諸情報の内容（処理依頼および処理データ）に実行履歴情報の内容（処理依頼および処理データ）が矛盾していないことであり、例えば、設計諸情報の処理データがある数値範囲で表されている場合に、実行履歴情報の処理データがその数値範囲にあることを意味する。
【００１３】
さて、出力手段が出力する判定結果としては、単に、一致か不一致かを出力するようにしても良いが、それのみでは、設計書にて規定されている内容の内、どの部分が現実と異なっているかを特定するのは容易でない。
そこで請求項２記載の様に、出力手段を、比較判定手段が実行履歴情報と設計書情報とが不一致であると判定すると、その実行履歴情報の内、設計書情報と不一致の箇所を出力する様に構成すると良い。この様に構成された請求項２記載のソフトウェア結合検査装置によれば、実行履歴情報の内、設計書情報と一致しない部分が出力されることから、新規のソフトウェアの内の修正すべき個所を特定し易くなるので好ましい。
【００１４】
ところで、検査対象のソフトウェアが、所定の制御対象物を制御するためのものである場合、設計書に規定される処理データは、その制御対象物を制御するための物理量で記述される一方、ソフトウェアが搭載されるマイクロコンピュータにおいては、物理量がＡ／Ｄ変換された制御データ（デジタル値）に基づいた処理が行われる。即ち、ソフトウェアが扱う処理データとして、物理量がＡ／Ｄ変換された制御データが扱われる。そのため、Ａ／Ｄ変換における分解能を考慮しなければ、設計書情報と実行履歴情報とを比較することができない。
【００１５】
そこで、検査対象のソフトウェアが、所定の制御対象物を制御するための物理量をＡ／Ｄ変換して得られる制御データに基づき、その制御対象物を制御するためのものであって、設計書には、処理データとして、その制御対象物を制御するための物理量が記述されている場合には、請求項３記載の様に、請求項１又は２に記載のソフトウェア結合検査装置において、Ａ／Ｄ変換により得られる制御データ毎に、そのＡ／Ｄ変換の際の分解能を表す分解能情報を記憶した分解能情報記憶手段を設け、実行履歴情報読取手段を、実行結果格納手段に記憶された実行結果から、分解能情報に基づき、処理データとしての制御データを読み取るよう構成するとよい。この様に構成された請求項３記載のソフトウェア結合検査装置によれば、実行結果格納手段に格納された実行結果から、制御データを実際の物理量として読み取ることから、実行履歴情報と設計書情報との比較が可能となる。
【００１６】
また、制御データのデータ型を符号付き（即ち、正数および負数を表現可能なデータ型）として扱うか、否かは、制御データ毎によって異なるのが普通であり、そして、そのデータ長も制御データ毎によって異なるのが普通である。これらを考慮しなければ、実行結果格納手段に記憶された実行結果から、制御データを正確に読み取ることはできない。
【００１７】
そこで、請求項４記載の様に、制御データ毎に、そのデータ型が符号付きか否かを表す符号情報を記憶した符号情報記憶手段を設け、実行履歴情報読取手段を、実行結果格納手段に記憶された実行結果から、符号情報に基づき制御データを読み取るよう構成すると良い。この様に構成された請求項４記載のソフトウェア結合検査装置によれば、制御データ毎に、符号付きか否かが異なる場合であっても、実行結果格納手段に記憶された実行結果から、正確な制御データの読み取りが可能となる。
【００１８】
そして、請求項５記載の様に、制御データ毎に、そのデータ長を表すデータ長情報を記憶したデータ長情報記憶手段を設け、実行履歴情報読取手段を、実行結果格納手段に記憶された実行結果から、データ長情報に基づき制御データを読み取るよう構成すると良い。この様に構成された請求項５記載のソフトウェア結合検査装置によれば、制御データ毎に、そのデータ長が異なる場合であっても、実行結果格納手段に記憶された実行結果から、正確な制御データの読み取りが可能となる。
【００１９】
【発明の実施の形態】
以下、本発明の一実施例として、車載電子制御装置（ＥＣＵ）に搭載するソフトウェアの開発において使用されるソフトウェア結合検査装置について、図面と共に説明する。
【００２０】
図１は、実施例のソフトウェア結合検査装置２の全体構成を表す説明図であり、図に示す様に、ソフトウェア結合検査装置２は、各種演算処理を行うＣＰＵの他、メモリ装置（例えばＲＯＭ、ＲＡＭ）等を備えたコンピュータ４と、このコンピュータ４に接続され、検査対象の設計書の整理番号（シナリオ番号）等の各種の情報を入力するための入力装置（キーボード６、マウス８等）と、このコンピュータ４に接続され画面表示可能な表示装置１０とを備えている。また、コンピュータ４には、画像表示データ格納サーバ１４およびロギングデータ格納サーバ１６が、通信線を介して接続されている。なお、画像表示データ格納サーバ１４が、請求項の「画像表示データ格納手段」に相当し、ロギングデータ格納サーバ１６が請求項の「実行結果格納手段」に相当する。また、表示装置１０が請求項の「出力手段」に相当する。
【００２１】
画像表示データ格納サーバ１４には、開発ターゲット（即ち本実施例では、ＥＣＵ）に要求される仕様をＭＳＣとして記述した多数の設計書の画像表示データが格納されている。この画像表示データは、文字データおよび図形データから構成されたものであり、その一例を図２（ａ）を用いて説明する。
【００２２】
図２（ａ）に例示するＭＳＣは、４つのオブジェクトＯｂｊ１，Ｏｂｊ２，Ｏｂｊ３，Ｏｂｊ４の結合を示したものである。ＭＳＣでは、各オブジェクトは「オブジェクト名」を示す文字及びその文字の下方に配置される縦線（以下「生存線」という）として示され、一のオブジェクトから他のオブジェクトへのメッセージ（処理依頼）は生存線の間に引かれた矢印として表示される。また、上から下に向かう方向は時間の経過を示しており、上方に表示されたメッセージから順に出力が行われることを示している。即ち、図２（ａ）に示すＭＳＣにおいては、まず最初にオブジェクトＯｂｊ１がＯｂｊ２へメッセージＭＳＧ１を出力し、次にオブジェクトＯｂｊ２がＯｂｊ３へメッセージＭＳＧ２を出力し、続いてオブジェクトＯｂｊ３がＯｂｊ４へメッセージＭＳＧ３を出力し、そしてオブジェクトＯｂｊ４がＯｂｊ３へメッセージＭＳＧ４を出力し、最後にオブジェクトＯｂｊ３がＯｂｊ１へメッセージＭＳＧ５を出力すべきことが示されている。
【００２３】
各オブジェクトは、メッセージを受けるとそれに対応した処理を行い、必要に応じて他のオブジェクトに対しメッセージを出力するが、メッセージの出力に当たって所定の条件が満たされる必要がある場合には、その満たされるべき条件（例えば、オブジェクトにより行われる処理で扱われる変数（処理データ）が、予め設定された値或いは所定範囲の値であること等）が、そのメッセージを示す矢印よりも上側であって生存線に重なるよう配置された枠の中に記述される。即ち、図２（ａ）に示すＭＳＣにおいては、処理データ「ｄａｔａ１」が「ＸＸＸ（数値或いは数値範囲）」という条件（即ち請求項の処理データ）を満たしている場合にのみ、オブジェクト０ｂｊ１がオブジェクト０ｂｊ２に対してメッセージＭＳＧ１を出力し、また、メッセージＭＳＧ１を受けたオブジェクト２は、処理データ「ｄａｔａ２」が「ＹＹＹ（数値或いは数値範囲）」という条件を満たしている場合にのみ、オブジェクト０ｂｊ３に対してメッセージＭＳＧ２を出力すべきことが示されている。なお、図２（ａ）に示す様に、各画像表示データには、個々の設計書を識別するためのシナリオ番号（ＺＺＺＺ）が付されている。
【００２４】
図１に戻り、一方、ロギングデータ格納サーバ１６にはプログラムの実行結果を示すデータが格納されている。この実行結果を示すデータは、プログラム設計書に従って作成されたソースプログラムＳが、実行可能なロードモジュールとして開発ターゲットであるＥＣＵ１８にて実行された途中経過を含む実行結果である。ＥＣＵ１８には、ＥＣＵ１８のマイクロプロセッサにより本来行われるべき動作を模擬的に実現するインサーキットエミュレー夕（ＩＣＥ）１８ａが接続されており、ロードモジュールに従って行われたＥＣＵ１８の動作結果はＩＣＥ１８ａにより抽出され、ロギングデータ格納サーバ１６に格納されている。
【００２５】
ソフトウェアの結合検査は、上記のように構成されたソフトウェア結合検査装置２を使用して、図３に示す検査処理により行われる。検査処理はソフトウェア結合検査装置２に対し、予め定められた命令をキーボード６から入力することにより起動される処理であり、起動されると、まず設計書情報の取込が行われる（Ｓ１００）。設計書情報の取込は、図４に示す設計書情報取込処理により行われるものであり、この設計書情報取込処理では、図２（ａ）に示す様なＭＳＣを構成する図形や文字を認識し、図面の左上部を基準点（原点）とした、それら図形や文字の位置を検出することにより、オブジェクト間におけるメッセージ出力の順序やメッセージ出力条件としての処理データ条件を読み取る。なお、本実施例のソフトウェア結合検査装置２においては、横方向にｘ軸、縦方向にｙ軸をとり、ｘｙ座標平面における図形や文字の位置が検出される。
【００２６】
図４に示す様に、設計書情報取込処理が起動されると、まずステップ（以下「ステップ」を「Ｓ」で示す）１０２にて、シナリオ番号を検出する。シナリオ番号を配置すべき位置は予め設定されており、その設定された位置に配置された文字を読み取ることによりシナリオ番号の取り込みが行われる。シナリオ番号を検出した後、Ｓ１０４では、シナリオ番号よりも下方であって、ｙ軸方向の予め設定された所定範囲をスキャンすることによって、その所定範囲内にある文字を認識し、その座標を取り込む。そしてＳ１０６では、Ｓ１０４にて検出された文字を読み取ることによりオブジェクト名を取り込み、Ｓ１０８では、その読み取った文字（即ちオブジェクト名）の存在する範囲（ｘ軸方向の範囲）にある直線を、生存線として認識し、その位置（ｘ座標）を取り込む。
【００２７】
そして、Ｓ１１０では、ｙ軸方向の上記所定範囲に、その他にもオブジェクト名を示す文字がないかどうかを判断し、他にもある場合には（Ｓ１１０：ＮＯ）、Ｓ１０４に戻り、上記Ｓ１０４〜Ｓ１０８の処理を再び行う。つまり、Ｓ１０４〜Ｓ１０８の処理の繰り返しにより、当該ＭＳＣにて記述されているオブジェクトの名称（即ちオブジェクト名）及びそのオブジェクトに対応する生存線の位置（ｘ座標）が検出されることとなり、例えば図２（ａ）に示すＭＳＣにおいては、「０ｂｊ１」、「０ｂｊ２」、「０ｂｊ３」及び「０ｂｊ４」というオブジェクト名とそれらに対応する生存線の位置が検出されることとなる。その後、Ｓ１１０において、ｙ軸方向の上記所定範囲には、他にオブジェクト名を示す文字がない（ＹＥＳ）と判断されると、Ｓ１１２に移行する。
【００２８】
Ｓ１１２では、ｙ軸方向の上記所定範囲よりも更に下方に向かって（即ち時系列順に）スキャンすることにより、メッセージ出力条件としての処理データの条件を示した文字或いはメッセージを示す文字（これらをアイテムという）を探す。そしてＳ１１２にてアイテムが検出されると、その検出されたアイテムがメッセージを示すものか否かを、その直下に矢印があるか否かにより判断する（Ｓ１１４）。即ち、アイテムの直下に矢印がある場合には、メッセージであると判断し（Ｓ１１４：ＹＥＳ）、そのアイテムをメッセージ名として検出し（Ｓ１１６）、更に矢印の始点及び終点の座標を読み込み、上記検出した生存線のｘ座標に基づき、メッセージの発行元のオブジェクト及び送り先のオブジェクトを特定してメモリ装置に格納する（Ｓ１１８）。
【００２９】
一方、Ｓ１１４においてメッセージでない（ＮＯ）と判断すると、Ｓ１２０に移行して、上記アイテムが処理データの条件を示すものか否かを、それが枠で囲まれているか否かにより判断する（Ｓ１２０）。アイテムが枠で囲まれている場合には、処理データの条件であると判断し（Ｓ１２０：ＹＥＳ）、その枠内に配置された文字の内、左辺の文字を処理データ名として検出し（Ｓ１２２）、右辺の文字を処理データが取るべき値或いは値の範囲として読み込む（Ｓ１２４）。
【００３０】
そして、Ｓ１１２にて検出されたアイテムが、メッセージでもなく処理データの条件でもないもの（例えばソフトウェア結合検査のオプション機能用のアイテム等）である場合（Ｓ１２０：ＮＯ）には、そのアイテムに対して予め設定されているシステム処理を行う（Ｓ１２６）。
【００３１】
こうしてＳ１１２で検出されたアイテムの種類に応じた処理が行われると、Ｓ１２８に移行し、更に下方に向かってスキャンすることにより他のアイテムがないかどうかを判断し、他にもある場合（Ｓ１２８：ＮＯ）にはＳ１１２に戻る。一方、他にアイテムがないと判断した場合には（Ｓ１２８：ＹＥＳ）、Ｓ１３０に移行する。Ｓ１３０では、上述の一連の処理にて検出されたメッセージや処理データに関するデータ（処理データ名、処理データ条件、メッセージ名、オブジェクト名等）を、検出したアイテムのｙ座標に基づき時系列順にソートしてメモリ装置に格納した後、当該設計書情報取込処理を終了する。なお、この設計書情報取込処理は、請求項の「設計書情報読取手段」の一部として機能する。
【００３２】
以上の様にして、設計書情報取込処理において、画像表示データ格納サーバ１４内の画像表示データが、設計書に規定されている処理データの条件やオブジェクト間におけるメッセージ出力の出力順序等を示す所定の形式に変換されたデータとしてメモリ装置に格納される。即ち、図２（ａ）に示すＭＳＣは、図２（ｂ）の様な設計書情報として、コンピュータ４のメモリ装置に格納されることとなる。  なお、処理データ名、メッセージ名、オブジェクト名には、夫々に対応するデータＩＤ、メッセージＩＤ、オブジェクトＩＤが、所定のテーブルにて定められている（このうち処理データ名とデータＩＤとの対応関係を規定している変換テーブルを図７に示す）。即ち、Ｓ１３０では、上記ソートが行われるほか、検出された処理データ名、メッセージ名、オブジェクト名は、夫々、データＩＤ、メッセージＩＤ、オブジェクトＩＤに変換された後、設計書情報として格納される。
【００３３】
図３に戻り説明を続ける。上述の様に設計書情報の取込を行った（Ｓ１００）後、次にロギングデータの取込を行う（Ｓ２００）。ロギングデータの取込は、ロギングデータ格納サーバ１６に格納された実行結果（ロギングデータ）を示すデータを読込み、上記の設計書情報と比較し易い形式のロギングデータに変換するものである。図５にロギングデータの概念図を示す。図５において、図５（ａ）が実際のロギングデータを示す図であるが、１６進で書かれたデータの羅列のため、この内容説明に合わせたものを、図５（ｂ）に示す。
【００３４】
図５（ｂ）に示す様に、ロギングデータは、プログラムの実行履歴（メッセージ出力や制御データ等）が時系列的に格納された、多数のブロック（８バイト）で構成されており、各ブロック毎に、そのブロックが、どういった情報を格納しているかを示すデータ種別（２バイト）が付されている。データ種別が「０１００」であるブロックには、発行元のオブジェクトＩＤ、送り先のオブジェクトＩＤおよびメッセージＩＤといったメッセージ出力に関する情報が格納されており、データ種別が「０２００」であるブロックには、データＩＤおよびデータ値といった制御データに関する情報が格納されている。なお、ロギングデータには、所定の物理量をＡ／Ｄ変換して得られる制御データだけでなく、制御データ以外の処理データが記録されているが、簡単の為、統一して「制御データ」ということとする。
【００３５】
さて、ＥＣＵ１８では多数のＭＳＣに基づいて作成されたソフトウェアプログラムが連続して実行され、そしてロギングデータは、それら一連の実行履歴が記録されたものであることから、メッセージ或いは制御データに関する情報を格納したブロックが、夫々、どのＭＳＣに対応する実行履歴であるかが示される必要がある。そのため、同一のＭＳＣに対応する一連のブロック群の前後には、先頭（スタート（００００））或いは最後尾（エンド（ＦＦ００））を示すデータ種別が付されたブロックが挿入されている。データ種別が「００００」である先頭のブロックには、対応するＭＳＣのシナリオ番号が格納されている。なお、Ｓ２００の処理は、請求項の「実行履歴読取手段」の一部として機能する。
【００３６】
この様なロギングデータの取込（Ｓ２００）が行われると、Ｓ１００にて設計書情報として取り込まれた設計書のシナリオ番号に基づいて、ロギングデータの内の検査対象が特定され（Ｓ３００）、図６に示す比較処理が起動される（Ｓ４００）。
【００３７】
この比較処理は、コンピュータ４に入力されたシナリオ番号に対応する設計書情報（図２（ｂ））およびロギングデータ（図５）とを１ブロックずつ時系列順に読み出し、互いに比較することにより、ロギングデータと設計書情報との一致、不一致を検出するものであり、起動されると、まずＳ４０２において、上記Ｓ３００で特定された検査対象の内のロギングデータの１ブロックを読込み、その１ブロックの最初の２バイトに格納されている「データ種別」に基づいて、制御データか否かを判別する（Ｓ４０２）。本実施例では、上述の様に「０１００」ならメッセージ、「０２００」なら制御データを示している。
【００３８】
そして、制御データと判断された場合（Ｓ４０２：ＹＥＳ）、「データ種別」に続く２バイトの領域に格納されている「データＩＤ」を読込み（Ｓ４０４）、コンピュータ４のメモリ装置内に予め格納されている変換テーブル（図７）を参照して、その検出したデータＩＤに対応する制御データのデータ長（データサイズ、size）を読み取ると共に（Ｓ４０６）、その制御データが符号付きか否か（符号有無、型）を読み取る（Ｓ４０８）。
【００３９】
ここで、「データサイズ」とは、全４バイトの制御データ用の領域の内、何バイトが、制御データの表現に使用されているかを示す情報である。例えば、Ｓ４０４にて、データＩＤとして「１０」が得られた場合（即ち出力軸回転数）には、制御データ用の領域（４バイト）の内、２バイトが制御データの表現に使用されていることが、図７の変換テーブルから分かる。尚、「データサイズ」が請求項の「データ長情報」に相当する。
【００４０】
また、「符号有無」とは、制御データが、負数を含むか或いは正数のみかを示すものである。制御データが１バイト長である場合、符号なしである正数型（ｕ）として定義されているときには、１０進法の「０」〜「２５５」を表すので、２進法の「１１１１１１１１」は「２５５」を示すが、符号付きである負数型（ｓ）として定義されている場合には、１０進法の「−１２８」〜「１２７」を表すので、同じ２進法の「１１１１１１１１」であっても１０進法の「−１」を示すことになる。よって、制御データの内容を正しく検出するためには、「符号有無」を確認する必要があるのである。なお、例えばＳ４０４にて、データＩＤが「１０」である場合には、図７の変換テーブルから、「符号あり（ｓ）」であることが分かる。尚、「符号有無」が請求項の「符号情報」に相当する。
【００４１】
Ｓ４０８の後、上記の「データサイズ」および「符号有無」を考慮して、「データＩＤ」に続く２バイトの領域に格納されている「データ値」を読み取ると共に、その「データＩＤ」に対応するＬＳＢ（１ビット当たりの分解能）を変換テーブルから求め、「データＩＤ」に続く２バイトの領域に格納されている「データ値」に乗算することにより、実際の制御データの値に換算する（Ｓ４１０）。即ち、ロギングデータとして記録されているデータ値には、実際の物理量がデジタル値（２進数）に変換された制御データの値であるものも含まれるので、そのままでは、設計書情報にて物理量にて規定されている処理データの条件と比較できない。そのため、ロギングデータとして記録されているデータ値に、ＬＳＢを掛けることにより設計書情報に物理量にて規定されている処理データと比較可能な値に変換するのである。尚、この「ＬＳＢ」が請求項の「分解能情報」に相当する。そして、変換テーブルが、請求項の「分解能情報記憶手段」、「符号情報記憶手段」および「データ長情報記憶手段」として機能する。
【００４２】
こうして、Ｓ４０４〜Ｓ４１０の処理実行により、制御データを、設計書情報と比較できるようなデータとして読み取ると、次に、１ブロック分の設計書情報を読み込み、その１ブロック分の設計書情報とロギングデータとを（即ち、データＩＤおよびデータ値について）比較する（Ｓ４１２）。
【００４３】
そして、この比較（Ｓ４１４）の結果、設計書情報とロギングデータが一致しているか否かを判断し（Ｓ４１８）、両者（設計書情報とロギングデータ）が不一致の場合には（Ｓ４１８：ＮＯ）、当該ブロックのロギングデータ（データＩＤおよびデータ値）を、それが先頭ブロックから何ブロック目であるかを示すブロック番号等と共に、メモリ装置に保持した後（Ｓ４２０）、Ｓ４２２に移行する。これは、後述する様に、不一致箇所のロギングデータがどの様な値（ＮＧデータ）であったかを表示装置１０に表示させるために保持するものである。一方、設計書情報とロギングデータとが一致している場合には（Ｓ４１８：ＹＥＳ）、Ｓ４２２にそのまま移行する。
【００４４】
ところで、Ｓ４０２にて読み込んだ、ロギングデータの１ブロックが制御データを格納するものでない場合（即ちメッセージである場合）には（Ｓ４０２：ＮＯ）、設計書情報の１ブロック分を読み込み（Ｓ４１５）、その１ブロック分の設計書情報とロギングデータとを（即ち、発行元のオブジェクトＩＤ、送り先のオブジェクトＩＤおよびメッセージＩＤについて）比較する（Ｓ４１６）。
【００４５】
そして、この比較（Ｓ４１６）の結果、設計書情報とロギングデータが一致しているか否かを判断し（Ｓ４１８）、両者（設計書情報とロギングデータ）が不一致の場合には（Ｓ４１８：ＮＯ）、当該ブロックのロギングデータ（発行元のオブジェクトＩＤ、送り先のオブジェクトＩＤおよびメッセージＩＤ）を、それが先頭ブロックから何ブロック目であるかを示すブロック番号等と共に、メモリ装置に保持した後（Ｓ４２０）、Ｓ４２２に移行する。一方、設計書情報とロギングデータとが一致している場合には（Ｓ４１８：ＹＥＳ）、Ｓ４２２にそのまま移行する。
【００４６】
Ｓ４２２では、上記Ｓ４０２にて読み込んだ１ブロックのロギングデータに続いて、別の１ブロックを読込み、そのブロックに付されたデータ種別が、「エンド」であるか否か（本実施例では、データ種別が「ＦＦ００」か否か）を判断し、「エンド」でなければ（Ｓ４２２：ＮＯ）、Ｓ４０２に戻って上記の処理を再び行うが、「エンド」であれば（Ｓ４２２：ＹＥＳ）、当該比較処理を終了する。  つまり、比較処理では、Ｓ３００で特定されたロギングデータの全ブロックについて、対応する設計書情報と比較し、不一致の箇所があれば、その部分のロギングデータを保持するのである。なお、上述のＳ４０４〜Ｓ４１０の処理が、請求項の「実行履歴情報読取手段」の一部として機能し、Ｓ４１２およびＳ４１５の処理が、請求項の「設計書情報読取手段」の一部として機能し、Ｓ４１４、Ｓ４１６およびＳ４１８の処理が、請求項の「比較判定手段」として機能する。
【００４７】
図３に戻り、Ｓ４００の比較処理の後、Ｓ５００に移行し、比較処理による比較結果が表示装置１０に画面表示される。即ち、表示装置１０には、設計書情報に基づいてＭＳＣが描かれ、比較結果が全て一致する場合（即ち、ＮＧデータがない場合）には“比較ＯＫ”と表示され、不一致部分がある場合には、“比較ＮＧ”という表示が行われると共に、上記Ｓ４２０にてＮＧデータとして格納されたロギングデータに基づいて、不一致の箇所が強調すべく色分けして表示される。その結果、設計書（即ちＭＳＣ）通りに、ソフトウェア部品の結合がなされていない場合には、直ちに問題箇所が発見される。
【００４８】
なお、Ｓ５００において設計書情報やロギングデータに基づいてＭＳＣが描かれる際には、データＩＤと制御データ名およびその制御データが所属するオブジェクト名との対応関係が規定された変換テーブル（図７）や、オブジェクトＩＤとオブジェクト名との対応関係やメッセージＩＤとメッセージ名との対応関係が規定されたテーブル（図示せず）が参照される。
【００４９】
以上の様に構成された動作する本実施例のソフトウェア結合検査装置によれば、以下の効果を奏する。（１）設計書の画像表示データから設計書情報を読み取り、一方、ＥＣＵ１８における実行結果からロギングデータを読み取り、その設計書情報とロギングデータとを比較し、両情報の一致・不一致を判定して、その判定結果を出力する。その結果、複数のソフトウェア部品を結合して作成したソフトウェアにおいて設計書通りの処理動作が実現されているか否かを容易に判断することができる。しかも、両情報の比較は、ソフトウェア部品間におけるメッセージの出力履歴（即ち処理依頼）だけでなく、メッセージの出力条件である制御データの履歴（即ち処理依頼の出力条件）についても行うので、ソフトウェア部品の結合の良否判断をより確実に行うことができる。
【００５０】
（２）ロギングデータと設計書情報とが不一致である場合には、そのロギングデータの内、設計書情報と不一致の箇所を出力することから、新規のソフトウェアの内の修正すべき個所を特定し易くなる。即ち、不一致箇所を表示することで、誤り箇所を容易に特定できプログラミングのミスを素早く修正できる。
【００５１】
（３）制御データ毎に、その制御データに対応するＡ／Ｄ変換の「ＬＳＢ」を記録した変換テーブル（図７）を備えており、そのテーブルに基づき、デジタル値で表現された制御データを読み取ることから、ロギングデータと設計書情報との比較が可能となる。
【００５２】
（４）制御データ毎に、そのデータ型が符号付きか否かを表す「符号有無」を記録した変換テーブル（図７）を備え、このテーブルに基づき制御データを読み取ることから、制御データ毎に符号付きか否かが異なる場合であっても、正確な制御データの読み取りが可能となる。
【００５３】
（５）制御データ毎に、そのデータ長を表す「データサイズ」を記録した変換テーブル（図７）を備え、このテーブルに基づき制御データを読み取ることから、制御データ毎にデータ長が異なる場合であっても、正確な制御データの読み取りが可能となる。
【００５４】
尚、本発明の実施の形態は、上記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り、種々の形態を探り得ることは言うまでもない。
例えば、上記実施例では、ＥＣＵ１８上にて、検査対象であるソフトウェアを機能させた実行結果を、設計書との比較に使用しているが、これに限られるものではなく、コンピュータ上でのシミュレーションにより実行結果を得たものを使用しても良い。
【００５５】
また、上記実施例では、比較結果をＭＳＣの形で表示装置１０に表示するものとして説明したが、これに限られるものでなく、例えばリスト形式にして表示するようにしても良い。また、表示装置１０に限らず、例えばプリンタにより文書として出力しても良い。
【図面の簡単な説明】
【図１】  本発明の一実施例としてのソフトウェア結合検査装置の構成を示す説明図である。
【図２】  画像表示データとしての設計書（ＭＳＣ）および設計書情報の内容を示す説明図である。
【図３】  検査処理を示すフローチャートである。
【図４】  設計書情報取込処理を示すフローチャートである。
【図５】  ロギングデータの内容を示す説明図である。
【図６】  比較処理を示すフローチャートである。
【図７】  変換テーブルを示す説明図である。
【図８】  メッセージ・シーケンス・チャートの一例を示す説明図である。
【符号の説明】
２…ソフトウェア結合検査装置、４…コンピュータ、１０…表示装置、１４…画像表示データ格納サーバ、１６…ロギングデータ格納サーバ、Ｓ…ソースプログラム。
【図１】
0004200581.tif 000002
【図２】
0004200581.tif 000003
【図３】
0004200581.tif 000004
【図４】
0004200581.tif 000005
【図５】
0004200581.tif 000006
【図６】
0004200581.tif 000007
【図７】
0004200581.tif 000008
【図８】
0004200581.tif 000009