JP2000276375A - ソフトウェア結合検査装置 - Google Patents

Abstract

(57)【要約】 【課題】 複数のソフトウェア部品を結合して構成され
るソフトウェアの結合検査を効率良く行うことができる
ソフトウェア結合検査装置を提供する。 【解決手段】 設計書の画像表示データから設計書情報
を読み取り（Ｓ１００）、一方、ＥＣＵ１８における実
行結果からロギングデータを読み取り（Ｓ２００）、そ
の設計書情報とロギングデータとを比較し、両情報の一
致・不一致を判定して（Ｓ４００）、その判定結果を出
力する（Ｓ５００）。その結果、複数のソフトウェア部
品を結合して作成したソフトウェアによって設計書通り
の処理動作が実現されているか否かを容易に判断するこ
とができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、複数のソフトウ
ェア部品（ソフトウェアモジュール）を結合することに
より構成されるソフトウェアの結合検査を行うためのソ
フトウェア結合検査装置に関する。

【０００２】

【従来の技術】従来より、例えばオブジェクト指向のシ
ステム設計におけるソフトウェア開発では、複数のソフ
トウェア部品（オブジェクト指向では「オブジェクト」
としてとらえられる）を結合することにより、所望の機
能を有する新たなソフトウェアを開発することが行われ
ている。なお、オブジェクト指向とは、人間が行動する
ときの如く操作対象に注目して仕事を進めるという考え
方を、コンピュータシステムにモデル化したものであ
り、このオブジェクト指向のプログラミングでは、プロ
グラムの処理を、オブジェクトという単位で考える。オ
ブジェクトは、オブジェクト固有のデータとそのデータ
を扱う処理とを、一まとめにしたソフトウェアモジュー
ルである。

【０００３】オブジェクトの結合は、あるオブジェクト
から別のオブジェクトに対し、特定の処理を実行して欲
しい旨の「処理依頼（メッセージ）」が出力されること
によって図られ、メッセージを受けたオブジェクトで
は、そのメッセージにより特定される処理が行われる。
従って、オブジェクトの結合により作成すべき新たなソ
フトウェアにて所望の機能を実現するためには、各オブ
ジェクトからのメッセージの出力先、出力順序、出力条
件等を設計（メッセージ・シーケンスの設計）すること
が必要となる。そしてメッセージ・シーケンスの設計に
は、例えば図８に示す様な、メッセージ・シーケンス・
チャート（以下、「ＭＳＣ」という）という設計書が使
用されることが多い。

【０００４】図８はＭＳＣの一例を示す図であり、この
ＭＳＣでは、車両の自動変速装置の電子制御において、
出力軸回転数に応じて自動変速機の変速段を１速から２
速にシフトアップ（１−２変速）させる際に各オブジェ
クトが出力すべきメッセージが規定されている。このＭ
ＳＣにおいて、「変速出力マネージャ」は、トルクコン
バータの出力軸回転数に応じて変速段を決定するオブジ
ェクトであり、「シーケンスマネージャ」は、例えば
「現在変速中か否か」等の各種条件に基づいて変速可能
か否かを判断するオブジェクトである。そして、「制御
状態コントローラ」は、自動変速機内にある複数のソレ
ノイドバルブの内、どのバルブをどのタイミングで開閉
するかを決定するオブジェクトであり、「１−２変速制
御部品」は、１−２変速に必要なソレノイドバルブの駆
動制御を行うオブジェクトである。なお、「オブジェク
トが…する。」や「オブジェクトは…する。」といった
オブジェクトを主語とした動作表現は、実際には、コン
ピュータのＣＰＵがオブジェクトに従って動作する（換
言すれば、ＣＰＵがオブジェクトとして規定された処理
を実行する）ことで実現される機能手段が、上記「…」
の動作を行うことを意味する。

【０００５】そして、図８のＭＳＣでは、「変速出力マ
ネージャ」は「出力軸回転数＝２００〜５００ｒｐｍ」
と判断すると、「シーケンスマネージャ」に対して、１
−２変速が可能か否かの判断処理を要求するメッセージ
（１−２変速出力）を送ること、「シーケンスマネージ
ャ」は、変速可能か否かの判断を行い、その結果、変速
可能であるとき、変速種別を示す変速パターンＩＤを、
１−２変速に当たる「０」に変更して、「制御状態コン
トローラ」に、１−２変速制御の処理を要求するメッセ
ージ（１−２変速制御開始要求）を送ること、及び「制
御状態コントローラ」は、ソレノイドバルプを決定し、
決定されたソレノイドバルブを駆動するオブジェクトと
しての「１−２変速制御部品」に通電処理を要求するメ
ッセージ（通電開始要求）を送ることが、設計されてい
る。

【０００６】

【発明が解決しようとする課題】ところで、上記の様な
ＭＳＣに規定された結合を実現することを目標としてオ
ブジェクトが作成（即ち、ソースプログラムが記述）さ
れるが、その後、オブジェクト間の結合が設計通りに行
われ、ソフトウェア全体として設計通りの機能が満足さ
れるかどうかについての検査（所謂結合検査）が必要で
ある。こうした結合検査は、ソースプログラムとＭＳＣ
を目で見て比較することにより実施することも考えられ
る。即ちＭＳＣに記述された順番通りに、メッセージ出
力が行われているかどうかをソースプログラムを読んで
追っていくことにより、両者が比較される。

【０００７】しかし、それだけでは、実際に、その新た
に開発したソフトウェアによってハードウェアを動作さ
せた際に、ＭＳＣで規定されている機能・動作が実現さ
れるかどうかを確かめることはできない。また、単に処
理の実行順序を追うだけでは、上述の「出力軸回転数」
や「変速パターンＩＤ」といった、マイクロコンピュー
タ内で扱われる処理データ（制御データ）についての所
定条件（即ち、「出力軸回転数が２００ｒｐｍ以上５０
０ｒｐｍ以下」、「変速パターンＩＤが０」）が満たさ
れた上で、「１−２変速出力」、「１−２変速制御開始
要求」といったメッセージが出力されているかどうかを
確かめることはできない。

【０００８】例えば図８のＭＳＣにおいては、変速出力
マネージャは「出力軸回転数が２００〜５００ｒｐｍ」
であると判断すると、シーケンスマネージャに対して１
−２変速を要求するメッセージを出力することが規定さ
れているが、オブジェクト間におけるメッセージの流れ
のみを検査したのでは、実際の出力軸回転数が１０００
ｒｐｍであるにも拘わらずメッセージが出力（発行）さ
れてはいないか、などを検査することはできない。即
ち、実際の出力軸回転数が１０００ｒｐｍであるにも拘
わらず、１−２変速を要求するメッセージが出力されて
いたとしても、その誤りを発見することができない。

【０００９】なお、こうした問題は、オブジェクト指向
のシステム設計におけるソフトウェア開発に限られるも
のではなく、複数のソフトウェア部品の結合により新た
なソフトウェアを作成する場合であれば、同様な問題が
生ずる。本発明は、上記問題に鑑みなされたものであ
り、複数のソフトウェア部品を結合して構成されるソフ
トウェアの結合検査を効率良く行うことができるソフト
ウェア結合検査装置を提供することを目的とする。

【００１０】

【課題を解決するための手段及び発明の効果】上記課題
を解決するためになされた本発明（請求項１記載）のソ
フトウェア結合検査装置においては、設計書情報読取手
段が、画像表示データから、設計書上の文字及び図形の
位置を検出し、その検出結果に基づいて、ソフトウェア
部品間における処理依頼およびその処理データ条件を設
計書情報として読み取り、実行履歴情報読取手段が、設
計書に基づき作成されたソフトウェアの実行結果から、
ソフトウェア部品間における処理依頼履歴およびその出
力条件としての処理データを実行履歴情報として時系列
順に読み取り、比較手段が実行履歴情報と設計書情報と
を比較して、その両情報の一致・不一致を判定し、出力
手段が、その判定結果を当該ソフトウェア結合検査装置
外部に出力する。

【００１１】即ち、請求項１のソフトウェア結合検査装
置においては、設計書の画像表示データから設計書情報
（即ち設計書中に規定されているソフトウェア部品間に
おける処理依頼およびその出力条件としての処理データ
条件）を読み取り、一方、実行結果から実行履歴情報
（即ち、ソフトウェア部品間における処理依頼履歴およ
びその出力条件としての処理データ）を読み取り、その
設計書情報と実行履歴情報とを比較し、両情報の一致・
不一致を判定して、その判定結果を出力する。なお、両
情報の比較とは、設計書情報に規定されている処理依頼
と実行履歴情報内の処理依頼履歴との比較、および、設
計書情報に規定されている処理データ条件と実行履歴情
報内の処理データとの比較により図られる。

【００１２】そのため、請求項１記載のソフトウェア結
合検査装置によれば、複数のソフトウェア部品を結合し
て作成したソフトウェアによって設計書通りの処理動作
が実現されているか否かを容易に判断することができ
る。しかも、両情報の比較は、ソフトウェア部品間にお
ける処理依頼履歴だけでなく、処理依頼の出力条件につ
いても行うので、正しい条件で他のソフトウェア部品に
処理依頼されているかなど、ソフトウェア部品の結合の
良否判断をより確実に行うことができる。なお、設計書
情報と実行履歴情報とが「一致している」とは、設計諸
情報の内容（処理依頼および処理データ条件）に実行履
歴情報の内容（処理依頼履歴および処理データ）が矛盾
していないことであり、例えば、処理データ条件がある
数値範囲で表されている場合に、実行履歴情報の処理デ
ータがその数値範囲にあることを意味する。

【００１３】さて、出力手段が出力する判定結果として
は、単に、一致か不一致かを出力するようにしても良い
が、それのみでは、設計書にて規定されている内容の
内、どの部分が現実と異なっているかを特定するのは容
易でない。そこで請求項２記載の様に、出力手段を、比
較判定手段が実行履歴情報と設計書情報とが不一致であ
ると判定すると、その実行履歴情報の内、設計書情報と
不一致の箇所を出力する様に構成すると良い。この様に
構成された請求項２記載のソフトウェア結合検査装置に
よれば、実行履歴情報の内、設計書情報と一致しない部
分が出力されることから、新規のソフトウェアの内の修
正すべき個所を特定し易くなるので好ましい。

【００１４】ところで、検査対象のソフトウェアが、所
定の制御対象物を制御するためのものである場合、設計
書に規定される処理データ条件は、その制御対象物を制
御するための物理量で記述される一方、ソフトウェアが
搭載されるマイクロコンピュータにおいては、物理量が
Ａ／Ｄ変換された制御データ（デジタル値）に基づいた
処理が行われる。即ち、ソフトウェアが扱う処理データ
として、物理量がＡ／Ｄ変換された制御データが扱われ
る。そのため、Ａ／Ｄ変換における分解能を考慮しなけ
れば、設計書情報と実行履歴情報とを比較することがで
きない。

【００１５】そこで、検査対象のソフトウェアが、所定
の制御対象物を制御するための物理量をＡ／Ｄ変換して
得られる制御データに基づき、その制御対象物を制御す
るためのものであって、設計書には、処理データ条件と
して、その制御対象物を制御するための物理量が記述さ
れている場合には、請求項３記載の様に、請求項１又は
２に記載のソフトウェア結合検査装置において、Ａ／Ｄ
変換により得られる制御データ毎に、そのＡ／Ｄ変換の
際の分解能を表す分解能情報を記憶した分解能情報記憶
手段を設け、実行履歴情報読取手段を、実行結果格納手
段に記憶された実行結果から、分解能情報に基づき、処
理データとしての制御データを読み取るよう構成すると
よい。この様に構成された請求項３記載のソフトウェア
結合検査装置によれば、実行結果格納手段に格納された
実行結果から、制御データを実際の物理量として読み取
ることから、実行履歴情報と設計書情報との比較が可能
となる。

【００１６】また、制御データのデータ型を符号付き
（即ち、正数および負数を表現可能なデータ型）として
扱うか、否かは、制御データ毎によって異なるのが普通
であり、そして、そのデータ長も制御データ毎によって
異なるのが普通である。これらを考慮しなければ、実行
結果格納手段に記憶された実行結果から、制御データを
正確に読み取ることはできない。

【００１７】そこで、請求項４記載の様に、制御データ
毎に、そのデータ型が符号付きか否かを表す符号情報を
記憶した符号情報記憶手段を設け、実行履歴情報読取手
段を、実行結果格納手段に記憶された実行結果から、符
号情報に基づき制御データを読み取るよう構成すると良
い。この様に構成された請求項４記載のソフトウェア結
合検査装置によれば、制御データ毎に、符号付きか否か
が異なる場合であっても、実行結果格納手段に記憶され
た実行結果から、正確な制御データの読み取りが可能と
なる。

【００１８】そして、請求項５記載の様に、制御データ
毎に、そのデータ長を表すデータ長情報を記憶したデー
タ長情報記憶手段を設け、実行履歴情報読取手段を、実
行結果格納手段に記憶された実行結果から、データ長情
報に基づき制御データを読み取るよう構成すると良い。
この様に構成された請求項５記載のソフトウェア結合検
査装置によれば、制御データ毎に、そのデータ長が異な
る場合であっても、実行結果格納手段に記憶された実行
結果から、正確な制御データの読み取りが可能となる。

【００１９】

【発明の実施の形態】以下、本発明の一実施例として、
車載電子制御装置（ＥＣＵ）に搭載するソフトウェアの
開発において使用されるソフトウェア結合検査装置につ
いて、図面と共に説明する。

【００２０】図１は、実施例のソフトウェア結合検査装
置２の全体構成を表す説明図であり、図に示す様に、ソ
フトウェア結合検査装置２は、各種演算処理を行うＣＰ
Ｕの他、メモリ装置（例えばＲＯＭ、ＲＡＭ）等を備え
たコンピュータ４と、このコンピュータ４に接続され、
検査対象の設計書の整理番号（シナリオ番号）等の各種
の情報を入力するための入力装置（キーボード６、マウ
ス８等）と、このコンピュータ４に接続され画面表示可
能な表示装置１０とを備えている。また、コンピュータ
４には、画像表示データ格納サーバ１４およびロギング
データ格納サーバ１６が、通信線を介して接続されてい
る。なお、画像表示データ格納サーバ１４が、請求項の
「画像表示データ格納手段」に相当し、ロギングデータ
格納サーバ１６が請求項の「実行結果格納手段」に相当
する。また、表示装置１０が請求項の「出力手段」に相
当する。

【００２１】画像表示データ格納サーバ１４には、開発
ターゲット（即ち本実施例では、ＥＣＵ）に要求される
仕様をＭＳＣとして記述した多数の設計書の画像表示デ
ータが格納されている。この画像表示データは、文字デ
ータおよび図形データから構成されたものであり、その
一例を図２（ａ）を用いて説明する。

【００２２】図２（ａ）に例示するＭＳＣは、４つのオ
ブジェクトＯｂｊ１，Ｏｂｊ２，Ｏｂｊ３，Ｏｂｊ４の
結合を示したものである。ＭＳＣでは、各オブジェクト
は「オブジェクト名」を示す文字及びその文字の下方に
配置される縦線（以下「生存線」という）として示さ
れ、一のオブジェクトから他のオブジェクトへのメッセ
ージ（処理依頼）は生存線の間に引かれた矢印として表
示される。また、上から下に向かう方向は時間の経過を
示しており、上方に表示されたメッセージから順に出力
が行われることを示している。即ち、図２（ａ）に示す
ＭＳＣにおいては、まず最初にオブジェクトＯｂｊ１が
Ｏｂｊ２へメッセージＭＳＧ１を出力し、次にオブジェ
クトＯｂｊ２がＯｂｊ３へメッセージＭＳＧ２を出力
し、続いてオブジェクトＯｂｊ３がＯｂｊ４へメッセー
ジＭＳＧ３を出力し、そしてオブジェクトＯｂｊ４がＯ
ｂｊ３へメッセージＭＳＧ４を出力し、最後にオブジェ
クトＯｂｊ３がＯｂｊ１へメッセージＭＳＧ５を出力す
べきことが示されている。

【００２３】各オブジェクトは、メッセージを受けると
それに対応した処理を行い、必要に応じて他のオブジェ
クトに対しメッセージを出力するが、メッセージの出力
に当たって所定の条件が満たされる必要がある場合に
は、その満たされるべき条件（例えば、オブジェクトに
より行われる処理で扱われる変数（処理データ）が、予
め設定された値或いは所定範囲の値であること等）が、
そのメッセージを示す矢印よりも上側であって生存線に
重なるよう配置された枠の中に記述される。即ち、図２
（ａ）に示すＭＳＣにおいては、処理データ「ｄａｔａ
１」が「ＸＸＸ（数値或いは数値範囲）」という条件
（即ち請求項の処理データ条件）を満たしている場合に
のみ、オブジェクト０ｂｊ１がオブジェクト０ｂｊ２に
対してメッセージＭＳＧ１を出力し、また、メッセージ
ＭＳＧ１を受けたオブジェクト２は、処理データ「ｄａ
ｔａ２」が「ＹＹＹ（数値或いは数値範囲）」という条
件を満たしている場合にのみ、オブジェクト０ｂｊ３に
対してメッセージＭＳＧ２を出力すべきことが示されて
いる。なお、図２（ａ）に示す様に、各画像表示データ
には、個々の設計書を識別するためのシナリオ番号（Ｚ
ＺＺＺ）が付されている。

【００２４】図１に戻り、一方、ロギングデータ格納サ
ーバ１６にはプログラムの実行結果を示すデータが格納
されている。この実行結果を示すデータは、プログラム
設計書に従って作成されたソースプログラムＳが、実行
可能なロードモジュールとして開発ターゲットであるＥ
ＣＵ１８にて実行された途中経過を含む実行結果であ
る。ＥＣＵ１８には、ＥＣＵ１８のマイクロプロセッサ
により本来行われるべき動作を模擬的に実現するインサ
ーキットエミュレー夕（ＩＣＥ）１８ａが接続されてお
り、ロードモジュールに従って行われたＥＣＵ１８の動
作結果はＩＣＥ１８ａにより抽出され、ロギングデータ
格納サーバ１６に格納されている。

【００２５】ソフトウェアの結合検査は、上記のように
構成されたソフトウェア結合検査装置２を使用して、図
３に示す検査処理により行われる。検査処理はソフトウ
ェア結合検査装置２に対し、予め定められた命令をキー
ボード６から入力することにより起動される処理であ
り、起動されると、まず設計書情報の取込が行われる
（Ｓ１００）。設計書情報の取込は、図４に示す設計書
情報取込処理により行われるものであり、この設計書情
報取込処理では、図２（ａ）に示す様なＭＳＣを構成す
る図形や文字を認識し、図面の左上部を基準点（原点）
とした、それら図形や文字の位置を検出することによ
り、オブジェクト間におけるメッセージ出力の順序やメ
ッセージ出力条件としての処理データ条件を読み取る。
なお、本実施例のソフトウェア結合検査装置２において
は、横方向にｘ軸、縦方向にｙ軸をとり、ｘｙ座標平面
における図形や文字の位置が検出される。

【００２６】図４に示す様に、設計書情報取込処理が起
動されると、まずステップ（以下「ステップ」を「Ｓ」
で示す）１０２にて、シナリオ番号を検出する。シナリ
オ番号を配置すべき位置は予め設定されており、その設
定された位置に配置された文字を読み取ることによりシ
ナリオ番号の取り込みが行われる。シナリオ番号を検出
した後、Ｓ１０４では、シナリオ番号よりも下方であっ
て、ｙ軸方向の予め設定された所定範囲をスキャンする
ことによって、その所定範囲内にある文字を認識し、そ
の座標を取り込む。そしてＳ１０６では、Ｓ１０４にて
検出された文字を読み取ることによりオブジェクト名を
取り込み、Ｓ１０８では、その読み取った文字（即ちオ
ブジェクト名）の存在する範囲（ｘ軸方向の範囲）にあ
る直線を、生存線として認識し、その位置（ｘ座標）を
取り込む。

【００２７】そして、Ｓ１１０では、ｙ軸方向の上記所
定範囲に、その他にもオブジェクト名を示す文字がない
かどうかを判断し、他にもある場合には（Ｓ１１０：Ｎ
Ｏ）、Ｓ１０４に戻り、上記Ｓ１０４〜Ｓ１０８の処理
を再び行う。つまり、Ｓ１０４〜Ｓ１０８の処理の繰り
返しにより、当該ＭＳＣにて記述されているオブジェク
トの名称（即ちオブジェクト名）及びそのオブジェクト
に対応する生存線の位置（ｘ座標）が検出されることと
なり、例えば図２（ａ）に示すＭＳＣにおいては、「０
ｂｊ１」、「０ｂｊ２」、「０ｂｊ３」及び「０ｂｊ
４」というオブジェクト名とそれらに対応する生存線の
位置が検出されることとなる。その後、Ｓ１１０におい
て、ｙ軸方向の上記所定範囲には、他にオブジェクト名
を示す文字がない（ＹＥＳ）と判断されると、Ｓ１１２
に移行する。

【００２８】Ｓ１１２では、ｙ軸方向の上記所定範囲よ
りも更に下方に向かって（即ち時系列順に）スキャンす
ることにより、メッセージ出力条件としての処理データ
の条件を示した文字或いはメッセージを示す文字（これ
らをアイテムという）を探す。そしてＳ１１２にてアイ
テムが検出されると、その検出されたアイテムがメッセ
ージを示すものか否かを、その直下に矢印があるか否か
により判断する（Ｓ１１４）。即ち、アイテムの直下に
矢印がある場合には、メッセージであると判断し（Ｓ１
１４：ＹＥＳ）、そのアイテムをメッセージ名として検
出し（Ｓ１１６）、更に矢印の始点及び終点の座標を読
み込み、上記検出した生存線のｘ座標に基づき、メッセ
ージの発行元のオブジェクト及び送り先のオブジェクト
を特定してメモリ装置に格納する（Ｓ１１８）。

【００２９】一方、Ｓ１１４においてメッセージでない
（ＮＯ）と判断すると、Ｓ１２０に移行して、上記アイ
テムが処理データの条件を示すものか否かを、それが枠
で囲まれているか否かにより判断する（Ｓ１２０）。ア
イテムが枠で囲まれている場合には、処理データの条件
であると判断し（Ｓ１２０：ＹＥＳ）、その枠内に配置
された文字の内、左辺の文字を処理データ名として検出
し（Ｓ１２２）、右辺の文字を処理データが取るべき値
或いは値の範囲として読み込む（Ｓ１２４）。

【００３０】そして、Ｓ１１２にて検出されたアイテム
が、メッセージでもなく処理データの条件でもないもの
（例えばソフトウェア結合検査のオプション機能用のア
イテム等）である場合（Ｓ１２０：ＮＯ）には、そのア
イテムに対して予め設定されているシステム処理を行う
（Ｓ１２６）。

【００３１】こうしてＳ１１２で検出されたアイテムの
種類に応じた処理が行われると、Ｓ１２８に移行し、更
に下方に向かってスキャンすることにより他のアイテム
がないかどうかを判断し、他にもある場合（Ｓ１２８：
ＮＯ）にはＳ１１２に戻る。一方、他にアイテムがない
と判断した場合には（Ｓ１２８：ＹＥＳ）、Ｓ１３０に
移行する。Ｓ１３０では、上述の一連の処理にて検出さ
れたメッセージや処理データに関するデータ（処理デー
タ名、処理データ条件、メッセージ名、オブジェクト名
等）を、検出したアイテムのｙ座標に基づき時系列順に
ソートしてメモリ装置に格納した後、当該設計書情報取
込処理を終了する。なお、この設計書情報取込処理は、
請求項の「設計書情報読取手段」の一部として機能す
る。

【００３２】以上の様にして、設計書情報取込処理にお
いて、画像表示データ格納サーバ１４内の画像表示デー
タが、設計書に規定されている処理データの条件やオブ
ジェクト間におけるメッセージ出力の出力順序等を示す
所定の形式に変換されたデータとしてメモリ装置に格納
される。即ち、図２（ａ）に示すＭＳＣは、図２（ｂ）
の様な設計書情報として、コンピュータ４のメモリ装置
に格納されることとなる。 なお、処理データ名、メッ
セージ名、オブジェクト名には、夫々に対応するデータ
ＩＤ、メッセージＩＤ、オブジェクトＩＤが、所定のテ
ーブルにて定められている（このうち処理データ名とデ
ータＩＤとの対応関係を規定している変換テーブルを図
７に示す）。即ち、Ｓ１３０では、上記ソートが行われ
るほか、検出された処理データ名、メッセージ名、オブ
ジェクト名は、夫々、データＩＤ、メッセージＩＤ、オ
ブジェクトＩＤに変換された後、設計書情報として格納
される。

【００３３】図３に戻り説明を続ける。上述の様に設計
書情報の取込を行った（Ｓ１００）後、次にロギングデ
ータの取込を行う（Ｓ２００）。ロギングデータの取込
は、ロギングデータ格納サーバ１６に格納された実行結
果（ロギングデータ）を示すデータを読込み、上記の設
計書情報と比較し易い形式のロギングデータに変換する
ものである。図５にロギングデータの概念図を示す。図
５において、図５（ａ）が実際のロギングデータを示す
図であるが、１６進で書かれたデータの羅列のため、こ
の内容説明に合わせたものを、図５（ｂ）に示す。

【００３４】図５（ｂ）に示す様に、ロギングデータ
は、プログラムの実行履歴（メッセージ出力や制御デー
タ等）が時系列的に格納された、多数のブロック（８バ
イト）で構成されており、各ブロック毎に、そのブロッ
クが、どういった情報を格納しているかを示すデータ種
別（２バイト）が付されている。データ種別が「０１０
０」であるブロックには、発行元のオブジェクトＩＤ、
送り先のオブジェクトＩＤおよびメッセージＩＤといっ
たメッセージ出力に関する情報が格納されており、デー
タ種別が「０２００」であるブロックには、データＩＤ
およびデータ値といった制御データに関する情報が格納
されている。なお、ロギングデータには、所定の物理量
をＡ／Ｄ変換して得られる制御データだけでなく、制御
データ以外の処理データが記録されているが、簡単の
為、統一して「制御データ」ということとする。

【００３５】さて、ＥＣＵ１８では多数のＭＳＣに基づ
いて作成されたソフトウェアプログラムが連続して実行
され、そしてロギングデータは、それら一連の実行履歴
が記録されたものであることから、メッセージ或いは制
御データに関する情報を格納したブロックが、夫々、ど
のＭＳＣに対応する実行履歴であるかが示される必要が
ある。そのため、同一のＭＳＣに対応する一連のブロッ
ク群の前後には、先頭（スタート（００００））或いは
最後尾（エンド（ＦＦ００））を示すデータ種別が付さ
れたブロックが挿入されている。データ種別が「０００
０」である先頭のブロックには、対応するＭＳＣのシナ
リオ番号が格納されている。なお、Ｓ２００の処理は、
請求項の「実行履歴読取手段」の一部として機能する。

【００３６】この様なロギングデータの取込（Ｓ２０
０）が行われると、Ｓ１００にて設計書情報として取り
込まれた設計書のシナリオ番号に基づいて、ロギングデ
ータの内の検査対象が特定され（Ｓ３００）、図６に示
す比較処理が起動される（Ｓ４００）。

【００３７】この比較処理は、コンピュータ４に入力さ
れたシナリオ番号に対応する設計書情報（図２（ｂ））
およびロギングデータ（図５）とを１ブロックずつ時系
列順に読み出し、互いに比較することにより、ロギング
データと設計書情報との一致、不一致を検出するもので
あり、起動されると、まずＳ４０２において、上記Ｓ３
００で特定された検査対象の内のロギングデータの１ブ
ロックを読込み、その１ブロックの最初の２バイトに格
納されている「データ種別」に基づいて、制御データか
否かを判別する（Ｓ４０２）。本実施例では、上述の様
に「０１００」ならメッセージ、「０２００」なら制御
データを示している。

【００３８】そして、制御データと判断された場合（Ｓ
４０２：ＹＥＳ）、「データ種別」に続く２バイトの領
域に格納されている「データＩＤ」を読込み（Ｓ４０
４）、コンピュータ４のメモリ装置内に予め格納されて
いる変換テーブル（図７）を参照して、その検出したデ
ータＩＤに対応する制御データのデータ長（データサイ
ズ、size）を読み取ると共に（Ｓ４０６）、その制御デ
ータが符号付きか否か（符号有無、型）を読み取る（Ｓ
４０８）。

【００３９】ここで、「データサイズ」とは、全４バイ
トの制御データ用の領域の内、何バイトが、制御データ
の表現に使用されているかを示す情報である。例えば、
Ｓ４０４にて、データＩＤとして「１０」が得られた場
合（即ち出力軸回転数）には、制御データ用の領域（４
バイト）の内、２バイトが制御データの表現に使用され
ていることが、図７の変換テーブルから分かる。尚、
「データサイズ」が請求項の「データ長情報」に相当す
る。

【００４０】また、「符号有無」とは、制御データが、
負数を含むか或いは正数のみかを示すものである。制御
データが１バイト長である場合、符号なしである正数型
（ｕ）として定義されているときには、１０進法の
「０」〜「２５５」を表すので、２進法の「１１１１１
１１１」は「２５５」を示すが、符号付きである負数型
（ｓ）として定義されている場合には、１０進法の「−
１２８」〜「１２７」を表すので、同じ２進法の「１１
１１１１１１」であっても１０進法の「−１」を示すこ
とになる。よって、制御データの内容を正しく検出する
ためには、「符号有無」を確認する必要があるのであ
る。なお、例えばＳ４０４にて、データＩＤが「１０」
である場合には、図７の変換テーブルから、「符号あり
（ｓ）」であることが分かる。尚、「符号有無」が請求
項の「符号情報」に相当する。

【００４１】Ｓ４０８の後、上記の「データサイズ」お
よび「符号有無」を考慮して、「データＩＤ」に続く２
バイトの領域に格納されている「データ値」を読み取る
と共に、その「データＩＤ」に対応するＬＳＢ（１ビッ
ト当たりの分解能）を変換テーブルから求め、「データ
ＩＤ」に続く２バイトの領域に格納されている「データ
値」に乗算することにより、実際の制御データの値に換
算する（Ｓ４１０）。即ち、ロギングデータとして記録
されているデータ値には、実際の物理量がデジタル値
（２進数）に変換された制御データの値であるものも含
まれるので、そのままでは、設計書情報にて物理量にて
規定されている処理データの条件と比較できない。その
ため、ロギングデータとして記録されているデータ値
に、ＬＳＢを掛けることにより設計書情報に物理量にて
規定されている処理データと比較可能な値に変換するの
である。尚、この「ＬＳＢ」が請求項の「分解能情報」
に相当する。そして、変換テーブルが、請求項の「分解
能情報記憶手段」、「符号情報記憶手段」および「デー
タ長情報記憶手段」として機能する。

【００４２】こうして、Ｓ４０４〜Ｓ４１０の処理実行
により、制御データを、設計書情報と比較できるような
データとして読み取ると、次に、１ブロック分の設計書
情報を読み込み、その１ブロック分の設計書情報とロギ
ングデータとを（即ち、データＩＤおよびデータ値につ
いて）比較する（Ｓ４１２）。

【００４３】そして、この比較（Ｓ４１４）の結果、設
計書情報とロギングデータが一致しているか否かを判断
し（Ｓ４１８）、両者（設計書情報とロギングデータ）
が不一致の場合には（Ｓ４１８：ＮＯ）、当該ブロック
のロギングデータ（データＩＤおよびデータ値）を、そ
れが先頭ブロックから何ブロック目であるかを示すブロ
ック番号等と共に、メモリ装置に保持した後（Ｓ４２
０）、Ｓ４２２に移行する。これは、後述する様に、不
一致箇所のロギングデータがどの様な値（ＮＧデータ）
であったかを表示装置１０に表示させるために保持する
ものである。一方、設計書情報とロギングデータとが一
致している場合には（Ｓ４１８：ＹＥＳ）、Ｓ４２２に
そのまま移行する。

【００４４】ところで、Ｓ４０２にて読み込んだ、ロギ
ングデータの１ブロックが制御データを格納するもので
ない場合（即ちメッセージである場合）には（Ｓ４０
２：ＮＯ）、設計書情報の１ブロック分を読み込み（Ｓ
４１５）、その１ブロック分の設計書情報とロギングデ
ータとを（即ち、発行元のオブジェクトＩＤ、送り先の
オブジェクトＩＤおよびメッセージＩＤについて）比較
する（Ｓ４１６）。

【００４５】そして、この比較（Ｓ４１６）の結果、設
計書情報とロギングデータが一致しているか否かを判断
し（Ｓ４１８）、両者（設計書情報とロギングデータ）
が不一致の場合には（Ｓ４１８：ＮＯ）、当該ブロック
のロギングデータ（発行元のオブジェクトＩＤ、送り先
のオブジェクトＩＤおよびメッセージＩＤ）を、それが
先頭ブロックから何ブロック目であるかを示すブロック
番号等と共に、メモリ装置に保持した後（Ｓ４２０）、
Ｓ４２２に移行する。一方、設計書情報とロギングデー
タとが一致している場合には（Ｓ４１８：ＹＥＳ）、Ｓ
４２２にそのまま移行する。

【００４６】Ｓ４２２では、上記Ｓ４０２にて読み込ん
だ１ブロックのロギングデータに続いて、別の１ブロッ
クを読込み、そのブロックに付されたデータ種別が、
「エンド」であるか否か（本実施例では、データ種別が
「ＦＦ００」か否か）を判断し、「エンド」でなければ
（Ｓ４２２：ＮＯ）、Ｓ４０２に戻って上記の処理を再
び行うが、「エンド」であれば（Ｓ４２２：ＹＥＳ）、
当該比較処理を終了する。 つまり、比較処理では、Ｓ
３００で特定されたロギングデータの全ブロックについ
て、対応する設計書情報と比較し、不一致の箇所があれ
ば、その部分のロギングデータを保持するのである。な
お、上述のＳ４０４〜Ｓ４１０の処理が、請求項の「実
行履歴情報読取手段」の一部として機能し、Ｓ４１２お
よびＳ４１５の処理が、請求項の「設計書情報読取手
段」の一部として機能し、Ｓ４１４、Ｓ４１６およびＳ
４１８の処理が、請求項の「比較判定手段」として機能
する。

【００４７】図３に戻り、Ｓ４００の比較処理の後、Ｓ
５００に移行し、比較処理による比較結果が表示装置１
０に画面表示される。即ち、表示装置１０には、設計書
情報に基づいてＭＳＣが描かれ、比較結果が全て一致す
る場合（即ち、ＮＧデータがない場合）には“比較Ｏ
Ｋ”と表示され、不一致部分がある場合には、“比較Ｎ
Ｇ”という表示が行われると共に、上記Ｓ４２０にてＮ
Ｇデータとして格納されたロギングデータに基づいて、
不一致の箇所が強調すべく色分けして表示される。その
結果、設計書（即ちＭＳＣ）通りに、ソフトウェア部品
の結合がなされていない場合には、直ちに問題箇所が発
見される。

【００４８】なお、Ｓ５００において設計書情報やロギ
ングデータに基づいてＭＳＣが描かれる際には、データ
ＩＤと制御データ名およびその制御データが所属するオ
ブジェクト名との対応関係が規定された変換テーブル
（図７）や、オブジェクトＩＤとオブジェクト名との対
応関係やメッセージＩＤとメッセージ名との対応関係が
規定されたテーブル（図示せず）が参照される。

【００４９】以上の様に構成された動作する本実施例の
ソフトウェア結合検査装置によれば、以下の効果を奏す
る。 （１）設計書の画像表示データから設計書情報を読み取
り、一方、ＥＣＵ１８における実行結果からロギングデ
ータを読み取り、その設計書情報とロギングデータとを
比較し、両情報の一致・不一致を判定して、その判定結
果を出力する。その結果、複数のソフトウェア部品を結
合して作成したソフトウェアにおいて設計書通りの処理
動作が実現されているか否かを容易に判断することがで
きる。しかも、両情報の比較は、ソフトウェア部品間に
おけるメッセージの出力履歴（即ち処理依頼履歴）だけ
でなく、メッセージの出力条件である制御データの履歴
（即ち処理依頼の出力条件）についても行うので、ソフ
トウェア部品の結合の良否判断をより確実に行うことが
できる。

【００５０】（２）ロギングデータと設計書情報とが不
一致である場合には、そのロギングデータの内、設計書
情報と不一致の箇所を出力することから、新規のソフト
ウェアの内の修正すべき個所を特定し易くなる。即ち、
不一致箇所を表示することで、誤り箇所を容易に特定で
きプログラミングのミスを素早く修正できる。

【００５１】（３）制御データ毎に、その制御データに
対応するＡ／Ｄ変換の「ＬＳＢ」を記録した変換テーブ
ル（図７）を備えており、そのテーブルに基づき、デジ
タル値で表現された制御データを読み取ることから、ロ
ギングデータと設計書情報との比較が可能となる。

【００５２】（４）制御データ毎に、そのデータ型が符
号付きか否かを表す「符号有無」を記録した変換テーブ
ル（図７）を備え、このテーブルに基づき制御データを
読み取ることから、制御データ毎に符号付きか否かが異
なる場合であっても、正確な制御データの読み取りが可
能となる。

【００５３】（５）制御データ毎に、そのデータ長を表
す「データサイズ」を記録した変換テーブル（図７）を
備え、このテーブルに基づき制御データを読み取ること
から、制御データ毎にデータ長が異なる場合であって
も、正確な制御データの読み取りが可能となる。

【００５４】尚、本発明の実施の形態は、上記の実施例
に何ら限定されることなく、本発明の技術的範囲に属す
る限り、種々の形態を探り得ることは言うまでもない。
例えば、上記実施例では、ＥＣＵ１８上にて、検査対象
であるソフトウェアを機能させた実行結果を、設計書と
の比較に使用しているが、これに限られるものではな
く、コンピュータ上でのシミュレーションにより実行結
果を得たものを使用しても良い。

【００５５】また、上記実施例では、比較結果をＭＳＣ
の形で表示装置１０に表示するものとして説明したが、
これに限られるものでなく、例えばリスト形式にして表
示するようにしても良い。また、表示装置１０に限ら
ず、例えばプリンタにより文書として出力しても良い。

【図面の簡単な説明】

【図１】 本発明の一実施例としてのソフトウェア結合
検査装置の構成を示す説明図である。

【図２】 画像表示データとしての設計書（ＭＳＣ）お
よび設計書情報の内容を示す説明図である。

【図３】 検査処理を示すフローチャートである。

【図４】 設計書情報取込処理を示すフローチャートで
ある。

【図５】 ロギングデータの内容を示す説明図である。

【図６】 比較処理を示すフローチャートである。

【図７】 変換テーブルを示す説明図である。

【図８】 メッセージ・シーケンス・チャートの一例を
示す説明図である。

【符号の説明】

２…ソフトウェア結合検査装置、４…コンピュータ、１
０…表示装置、１４…画像表示データ格納サーバ、１６
…ロギングデータ格納サーバ、Ｓ…ソースプログラム。

フロントページの続き Ｆターム(参考） 5B042 GA08 GB08 GC08 HH14 HH17 HH30 HH49 MA08 MA14 MC08 MC40 NN09 NN13 5B076 AB10 EC05

Claims (5)

【特許請求の範囲】
1. 【請求項１】 複数のソフトウェア部品の結合により構
   成され、該複数のソフトウェア間の処理依頼の授受によ
   り機能するソフトウェアを検査するためのソフトウェア
   結合検査装置であって、 ソフトウエア部品間における処理依頼およびその出力条
   件としての処理データ条件が文字および図形により時系
   列的に規定された設計書の画像表示データを格納する画
   像表示データ格納手段と、 該画像表示データ格納手段に記憶された画像表示データ
   から、前記設計書上の文字及び図形の位置を検出し、該
   検出結果に基づいて、ソフトウェア部品間における処理
   依頼およびその処理データ条件を設計書情報として読み
   取る設計書情報読取手段と、 前記設計書に基づき作成された前記ソフトウェアの実行
   結果を格納する実行結果格納手段と、 該実行結果格納手段に格納された実行結果から、ソフト
   ウェア部品間における処理依頼履歴およびその出力条件
   としての処理データを実行履歴情報として時系列順に読
   み取る実行履歴情報読取手段と、 該実行履歴情報読取手段にて読み取られた実行履歴情報
   を、前記設計書情報読取手段にて読み取られた設計書情
   報と比較し、該両情報の一致・不一致を判定する比較判
   定手段と、 該比較判定による判定結果を、当該ソフトウェア結合検
   査装置外部に出力する出力手段と、 を備えたことを特徴とするソフトウェア結合検査装置。
2. 【請求項２】 請求項１記載のソフトウェア結合検査装
   置において、 前記出力手段は、前記比較判定手段が前記実行履歴情報
   と前記設計書情報とが不一致であると判定すると、該実
   行履歴情報の内、前記設計書情報と不一致の箇所を出力
   することを特徴とするソフトウェア結合検査装置。
3. 【請求項３】 請求項１又は２記載のソフトウェア結合
   検査装置において、 検査対象のソフトウェアは、所定の制御対象物を制御す
   るための物理量をＡ／Ｄ変換して得られる制御データに
   基づき、該制御対象物を制御するためのものであって、 前記設計書には、前記処理データ条件として、前記制御
   対象物を制御するための物理量が記述されており、 前記Ａ／Ｄ変換により得られる制御データ毎に、そのＡ
   ／Ｄ変換の際の分解能を表す分解能情報を記憶した分解
   能情報記憶手段を備え、 前記実行履歴情報読取手段は、前記実行結果格納手段に
   記憶された実行結果から、前記分解能情報に基づき、前
   記処理データとして、前記制御データを読み取ることを
   特徴とするソフトウェア結合検査装置。
4. 【請求項４】 請求項３記載のソフトウェア結合検査装
   置において、 前記制御データ毎に、そのデータ型が符号付きか否かを
   表す符号情報を記憶した符号情報記憶手段を備え、 前記実行履歴情報読取手段は、前記実行結果格納手段に
   記憶された実行結果から、前記符号情報に基づき、前記
   制御データを読み取ることを特徴とするソフトウェア結
   合検査装置。
5. 【請求項５】 請求項３又は４記載のソフトウェア結合
   検査装置において、 前記制御データ毎に、そのデータ長を表すデータ長情報
   を記憶したデータ長情報記憶手段を備え、 前記実行履歴情報読取手段は、前記実行結果格納手段に
   記憶された実行結果から、前記データ長情報に基づき、
   前記制御データを読み取ることを特徴とするソフトウェ
   ア結合検査装置。