図面 (/)

技術 ソフトウェア障害情報をレポートするための装置

出願人 インターナショナル・ビジネス・マシーンズ・コーポレーション
発明者 菅野啓河田義人前寺正彦
出願日 2005年12月28日 (12年10ヶ月経過) 出願番号 2005-379254
公開日 2007年7月12日 (11年4ヶ月経過) 公開番号 2007-179431
状態 特許登録済
技術分野 デバッグ/監視 特定用途計算機 機械翻訳 文書処理装置
主要キーワード 画素データレベル 障害追跡 問題発生箇所 標準ボタン ウィンドウタイプ 利用箇所 レポート装置 障害レポート
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2007年7月12日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

グローバルユーザ環境からの、再現手順、問題発生箇所判別のためのソフトウェア障害レポートの自動化を行う装置、方法、およびプログラムを提供すること。

解決手段

(1)国際化対応で用いるソフトウェアリソースファイルから各言語に割り振られた各種のメッセージを含む情報を抜き出し、言語間の対応をつけた形で付加属性と共にデータベースとして格納する。(2)障害再現シナリオ障害報告スクリーンショットやその他機能に対して、上記(1)で用意されたリソース・データベースを用いてテキスト翻訳画像情報の翻訳などの処理を行う。各処理機能は、既存の障害管理ツールと有機的に結合する。これにより、ソフトウェアサポート業務におけるデータのやり取りにおいて、適時、情報の言語を切り替えることを可能とする装置、方法、およびプログラムを提供する。

概要

背景

近年のグローバル化の流れにそって、コンピュータ・システム、特にソウトウェアにおいては、開発作業保守作業、及びユーザに対するサポート窓口等の業務が、多国籍に渡る別個チームにより協業して行われるようになってきた。また、ユーザ自身国際化されたソウトウェアを各国の現地事業所でグローバルに使用することも珍しくない。しかし今日においても、このような多国籍、すなわち多言語に渡るソフトウェア使用環境サポート環境、開発、及び保守環境のもとでは、いったんソウトウェアに障害が発生した場合には、顧客サポート部門は、迅速な解決のために障害レポート等を翻訳し、適切な部署に伝える必要がある。例えば、ある国のユーザで障害が発生した場合、顧客サポート部門は、海外にある保守部門や、開発部門に障害の内容、再現方法等をその国の技術者等が理解できる言語に翻訳してレポートしなければならない。

ここで、文字テキスト)の翻訳自体をサポートするシステムや方法は多数知られている(例えば、特許文献1の多言語マニュアル作成装置、特許文献2の対訳表示方法、特許文献3の多言語文書作成システム、等)。また、文字だけでなく画像と文字が混在したデータから文字部分のみを認識し、翻訳する装置等も開示されている(例えば、特許文献4、5)。
特開2004−280275号公報
特開2001−337950号公報
特開2001−297083号公報
特開2003−122751号公報
特開2002−108855号公報
特開2002− 73959号公報

概要

グローバルなユーザ環境からの、再現手順、問題発生箇所判別のためのソフトウェア障害レポートの自動化を行う装置、方法、およびプログラムを提供すること。(1)国際化対応で用いるソフトウェアのリソースファイルから各言語に割り振られた各種のメッセージを含む情報を抜き出し、言語間の対応をつけた形で付加属性と共にデータベースとして格納する。(2)障害再現シナリオ障害報告スクリーンショットやその他機能に対して、上記(1)で用意されたリソース・データベースを用いてテキスト翻訳や画像情報の翻訳などの処理を行う。各処理機能は、既存の障害管理ツールと有機的に結合する。これにより、ソフトウェアサポート業務におけるデータのやり取りにおいて、適時、情報の言語を切り替えることを可能とする装置、方法、およびプログラムを提供する。

目的

本発明は、上記のような様々な課題を解決するためになされたものであり、グローバルなユーザ環境からの、再現手順、問題発生箇所判別のためのソフトウェア障害レポートの自動化を行うシステム等を提供することを目的とする。

効果

実績

技術文献被引用数
1件
牽制数
2件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

複数の言語に渡るソフトウェア障害レポートのための装置であって、障害サポート対象ソフトウェア、および該ソフトウェアの実行のために使用され、複数の言語に対応した、複数のリソースファイルを探索し、前記リソースファイルのそれぞれからメッセージキーと該メッセージキーに対応する文字列を抽出してこれらを収集し、ならびに、前記文字列を翻訳するための手がかりを与える前記文字列に対する付加属性を抽出する、リソース探索部と、前記リソース探索部によって抽出された前記文字列および前記付加属性を記憶する、リソースデータベースと、前記障害サポート対象のソフトウェアに対する障害を記述した障害レポートから翻訳が必要な文字列を抽出し、前記リソース・データベースを参照して、前記障害レポートに前記文字列を翻訳して埋め込む、翻訳アダプタ部と、を備える装置。

請求項2

前記障害レポートに画像が含まれる場合に、該画像から文字列と文字列以外の画像を分離し、前記文字列に対する翻訳文字列を前記分離された画像に埋め込む画面変換部を更に備える、請求項1に記載の装置。

請求項3

前記リソース探索部は、前記付加属性を該ソフトウェアのソースコードファイル走査することによって取得する、請求項1に記載の装置。

請求項4

前記リソース探索部は、該ソフトウェアの実行時のウィンドウID、および利用ファイルの少なくとも一つから前記付加属性を抽出し、前記リソース・データベースに格納する、請求項1に記載の装置。

請求項5

前記リソース・データベースは、該ソフトウェアが使用する標準ボタンアイコンに関する情報を保持する、請求項1に記載の装置。

請求項6

前記リソース・データベースは、リソースファイルにおける命名規則を保持する、請求項1に記載の装置。

請求項7

前記翻訳アダプタ部は、前記リソース探索部が抽出した文字列から翻訳文字列を選択する際に曖昧性を除去する、請求項1に記載の装置。

請求項8

前記翻訳アダプタ部は、前記障害レポートに画像が含まれることを判断し、画像が含まれる場合に前記画面変換部に該画像から文字列と文字列以外の画像とを分離させる、請求項2に記載の装置。

請求項9

前記翻訳アダプタ部は、前記障害レポートとして再現シナリオスクリプトテキスト形式レポートを処理する、請求項1に記載の装置。

請求項10

前記画面変換部は、該画像から文字列を分離するためのOCR機能を含む、請求項2に記載の装置。

請求項11

前記画面変換部は、ダイアログ既定色情報、またはダイアログの既定フォント情報の少なくとも一つを用いて該画像から文字列を抽出する、請求項2に記載の装置。

請求項12

前記画面変換部は、該画像に含まれるアイコンを判別する、請求項2に記載の装置。

請求項13

前記画面変換部は、翻訳後の文字列が画像に収まらない場合に微調整を行う、請求項2に記載の装置。

請求項14

前記画面変換部は、文字列を右から左に書く言語に対応して該画像を左右反転させた後に翻訳後の文字列を埋め込む、請求項2に記載の装置。

請求項15

前記画面変換部は、フォントデータから言語によって使用頻度の高い文字を選びパターンを比較することによって文字列を抽出する、請求項2に記載の装置。

請求項16

前記画面変換部は、色調情報を用いて輝度彩度が離れている色の組み合わせからダイアログの背景色文字色を推測することによって文字列を抽出する、請求項2に記載の装置。

請求項17

複数の言語に渡るソフトウェア障害レポートのための方法であって、障害サポート対象のソフトウェア、および該ソフトウェアの実行のために使用され、複数の言語に対応した、複数のリソースファイルを探索し、前記リソースファイルからメッセージキーと該メッセージキーに対応する文字列を抽出してこれらを収集し、ならびに、前記文字列を翻訳するための手がかりを与える前記文字列に対する付加属性を抽出するステップと、前記抽出するステップによって抽出された前記文字列、および前記付加属性をリソース・データベースに記憶するステップと、前記障害サポート対象のソフトウェアに対する障害を記述した障害レポートから翻訳が必要な文字列を抽出し、前記リソース・データベースを参照して、前記障害レポートに前記文字列を翻訳して埋め込むステップと、を含む方法。

請求項18

前記障害レポートに画像が含まれる場合に、該画像から文字列と文字列以外の画像を分離し、前記文字列に対する翻訳文字列を前記分離された画像に埋め込むステップを更に含む請求項17に記載の方法。

請求項19

複数の言語環境で使用されるソフトウェアを含むコンピュータ・システムメンテナンスの方法であって、一つの言語によるソフトウェア障害レポートを他の言語に翻訳する際に、障害サポート対象のソフトウェアに関する情報からメッセージキーと該メッセージキーに対応する文字列を抽出してこれらを収集し、ならびに、前記文字列を翻訳するための手がかりを与える前記文字列に対する付加情報を抽出するステップと、前記抽出するステップによって抽出された文字列、および前記付加情報をデータベースに記憶するステップと、前記障害サポート対象のソフトウェアに対する障害レポートに含まれた翻訳が必要な文字列を抽出し、前記データベースを参照して、前記障害レポートに前記文字列を翻訳して埋め込むステップと、を含む方法。

請求項20

前記障害レポートに画像が含まれる場合に、該画像から文字列と文字列以外の画像を分離し、前記文字列に対する翻訳文字列を前記分離された画像に埋め込むステップを更に含む請求項19に記載の方法。

請求項21

複数の言語に渡るソフトウェア障害レポートのためのコンピュータ・プログラムであって、コンピュータに、障害サポート対象のソフトウェア、および該ソフトウェアの実行のために使用され、複数の言語に対応した、複数のリソースファイルを探索し、前記リソースファイルのそれぞれからメッセージキーと該メッセージキーに対応する文字列を抽出してこれらを収集し、ならびに、前記文字列を翻訳するための手がかりを与える前記文字列に対する付加属性を抽出するステップと、前記抽出するステップによって抽出された前記文字列、および前記付加属性をリソース・データベースに記憶するステップと、前記障害サポート対象のソフトウェアに対する障害を記述した障害レポートから翻訳が必要な文字列を抽出し、前記リソース・データベースを参照して、前記障害レポートに前記文字列を翻訳して埋め込むステップと、を実行させる、コンピュータ・プログラム。

請求項22

前記障害レポートに画像が含まれる場合に、該画像から文字列と文字列以外の画像を分離し、前記文字列に対する翻訳文字列を前記分離された画像に埋め込むステップを更に前記コンピュータに実行させる、請求項21に記載のコンピュータ・プログラム。

技術分野

0001

本発明は、障害情報レポートシステムに関する。更に詳しくは、多言語に渡るユーザ、サポート、開発保守環境におけるソフトウェア障害に関する障害レポートをするための装置、方法、およびプログラムに関する。

背景技術

0002

近年のグローバル化の流れにそって、コンピュータ・システム、特にソウトウェアにおいては、開発作業保守作業、及びユーザに対するサポート窓口等の業務が、多国籍に渡る別個チームにより協業して行われるようになってきた。また、ユーザ自身国際化されたソウトウェアを各国の現地事業所でグローバルに使用することも珍しくない。しかし今日においても、このような多国籍、すなわち多言語に渡るソフトウェアの使用環境、サポート環境、開発、及び保守環境のもとでは、いったんソウトウェアに障害が発生した場合には、顧客サポート部門は、迅速な解決のために障害レポート等を翻訳し、適切な部署に伝える必要がある。例えば、ある国のユーザで障害が発生した場合、顧客サポート部門は、海外にある保守部門や、開発部門に障害の内容、再現方法等をその国の技術者等が理解できる言語に翻訳してレポートしなければならない。

0003

ここで、文字テキスト)の翻訳自体をサポートするシステムや方法は多数知られている(例えば、特許文献1の多言語マニュアル作成装置、特許文献2の対訳表示方法、特許文献3の多言語文書作成システム、等)。また、文字だけでなく画像と文字が混在したデータから文字部分のみを認識し、翻訳する装置等も開示されている(例えば、特許文献4、5)。
特開2004−280275号公報
特開2001−337950号公報
特開2001−297083号公報
特開2003−122751号公報
特開2002−108855号公報
特開2002− 73959号公報

発明が解決しようとする課題

0004

しかしながら、上記の特許文献1〜5に開示された技術は、いずれも一般的な自然言語の翻訳の効率化を目指したものであり、多言語にわたる複雑な環境におけるソウトウェア障害レポートの効率化にはそのまま対処できるものではない。また、特許文献6に開示されているような障害受付システムも知られているが、このシステムでは、ユーザが希望する言語とともに障害受付センターアクセスを要求する必要があり、ユーザの希望言語での受付は可能になっても、その後の多国籍に渡るサポート部門、保守部門、及び開発部門の間の情報伝達障害解析に適用可能なものではない。

0005

ソフトウェア製品のユーザからの障害報告クレームは、通常、現地のカスタマサービスコールセンター等が受け、米国や、昨今では、インド、中国等の開発元に伝えられる。この間のやりとりに、異なった国籍担当者が、必然的に関わってくるため、言語障壁というボトルネックが常に存在する。例えば、インドに開発が外注された米国ソフトウェアベンダー製品が日本で販売された場合、日本語英語、印語といったリレーがなされる。

0006

クレーム対応への早さ、すなわち障害修正TAT(Turn Around Time)は、顧客満足直結しているため、この間の正確・迅速なやりとりが必須となる。しかし、製品機能精通し、かつ、語学堪能な人的リソースは限られている場合や、不測の事態余力を抱えていない場合も多い。従って、この間の処理を効率化する必要性がある。具体的には、ソフトウェア製品の障害対応は、例えば、以下の手順で行われる。日本の顧客は、日本にある販売代理店カスタマーセンターに障害を報告する。日本の担当者は日本語オペレーティング・システムで障害を再現し、再現手順を英語で障害管理システムに入力する(英訳のため、英語版オペレーティング・システム上での問題再現もなされる)。米国の開発リード(チームリーダ)は、障害の性質を評価し、プログラミング上のバグであれば、インド開発者に障害修正作業割り振る。

0007

昨今では、CRM(Customer Relationship Management)ソフトウェアの導入や、IBM(登録商標)製品では、CLERQEST(登録商標)という障害追跡、管理を行うツールを用い、顧客の問題処理を効率化しているが、これら製品には、顧客満足の定量的分析機能ナレッジデータベース機能、問題分類機能応答メール自動化機能等の効率化を助ける機能は多くあるが、実務上、最大のボトルネックとなることが多い異なった言語間リレーを効率化する機能は存在しない。

0008

図1は、現在のソフトウェア障害レポートの典型例を示している。ここでは、障害レポート10には、障害発生までの手順の他、製品Aの起動後選択されたメニューBの画面コピー11(スクリーンショット)、エラーメッセージ表示画面12、及びユーザまたはサポート部門の見解13が記述されている。このような障害レポートは、ユーザの使用した環境における言語でまず作成されるのが通常であり(この例では日本語)、サポート部門はこれを解析し適切な言語に翻訳して適切な部署に報告する必要がある。例えば、英語でレポートするためには、障害が実際に再現するかを確認するためにユーザが使用している環境と同等な英語環境を構築しなければならない。また、日本語環境で再現しても、英語環境で再現するとは限らないので動作環境の設定等にも細心の注意が必要である。仮に、再現に成功したとしても、スクリーンショットの取り直し、更に、メニュータイトル(この例ではメニューB)をそのソフトウェアが使用している適切な技術用語で正確に英語に翻訳しなければならず、このことは、多くのソフトウェア製品をサポートし、障害をレポートする側にとって大きな労力を必要とする。

0009

本発明は、上記のような様々な課題を解決するためになされたものであり、グローバルなユーザ環境からの、再現手順、問題発生箇所判別のためのソフトウェア障害レポートの自動化を行うシステム等を提供することを目的とする。

課題を解決するための手段

0010

本発明は、様々な実施形態において実現可能であるが、以下、主な実施形態についての解決手段について説明する。

0011

第一の実施形態では、
(A)複数の言語に渡るソフトウェア障害レポートのための装置であって、
(B)障害サポート対象のソフトウェア、および該ソフトウェアの実行のために使用され、複数の言語に対応した、複数のリソースファイルを探索し、前記リソースファイルのそれぞれからメッセージキーと該メッセージキーに対応する文字列を抽出してこれらを収集し、ならびに、前記文字列を翻訳するための手がかりを与える前記文字列に対する付加属性を抽出する、リソース探索部と、
(C)前記リソース探索部によって抽出された前記文字列および前記付加属性を記憶する、リソース・データベースと、
(D)前記障害サポート対象のソフトウェアに対する障害を記述した障害レポートから翻訳が必要な文字列を抽出し、前記リソース・データベースを参照して、前記障害レポートに前記文字列を翻訳して埋め込む、翻訳アダプタ部と、
を備える装置を提供する。

0012

また、上記装置は、
前記障害レポートに画像が含まれる場合に、該画像から文字列と文字列以外の画像を分離し、前記文字列に対する翻訳文字列を前記分離された画像に埋め込む画面変換部を更に備えることができる。

0013

第二の実施形態では、
(A)複数の言語に渡るソフトウェア障害レポートのための方法であって、
(B)障害サポート対象のソフトウェア、および該ソフトウェアの実行のために使用され、複数の言語に対応した、複数のリソースファイルを探索し、前記リソースファイルからメッセージキーと該メッセージキーに対応する文字列を抽出してこれらを収集し、ならびに、前記文字列を翻訳するための手がかりを与える前記文字列に対する付加属性を抽出するステップと、
(C)前記抽出するステップによって抽出された前記文字列、および前記付加属性をリソース・データベースに記憶するステップと、
(D)前記障害サポート対象のソフトウェアに対する障害を記述した障害レポートから翻訳が必要な文字列を抽出し、前記リソース・データベースを参照して、前記障害レポートに前記文字列を翻訳して埋め込むステップと、
を含む方法を提供する。

0014

上記方法は、
前記障害レポートに画像が含まれる場合に、該画像から文字列と文字列以外の画像を分離し、前記文字列に対する翻訳文字列を前記分離された画像に埋め込むステップを更に含むことができる。

0015

また、上記の方法は、コンピュータに上記機能を実行させるコンピュータ・プログラムとしても提供可能である。このコンピュータ・プログラムは、通信媒体を経由して提供されるか、あるいはそのプログラムを格納したコンピュータ可読の記録媒体としても提供される。

0016

更に別の実施形態では、
(A)複数の言語環境で使用されるソフトウェアを含むコンピュータ・システム・メンテナンスの方法であって、
(B)一つの言語によるソフトウェア障害レポートを他の言語に翻訳する際に、
(C)障害サポート対象のソフトウェアに関する情報からメッセージキーと該メッセージキーに対応する文字列を抽出してこれらを収集し、ならびに、前記文字列を翻訳するための手がかりを与える前記文字列に対する付加情報を抽出するステップと、
(D)前記抽出するステップによって抽出された文字列、および前記付加情報をデータベースに記憶するステップと、
(E)前記障害サポート対象のソフトウェアに対する障害レポートに含まれた翻訳が必要な文字列を抽出し、前記データベースを参照して、前記障害レポートに前記文字列を翻訳して埋め込むステップと、
を含む方法を提供する。

0017

以上の本発明の解決手段から得られる作用効果まとめると以下のようになる。
(1)国際化対応で用いるソフトウェアのリソースファイルから各言語に割り振られた各種のメッセージを含む情報を抜き出し、言語間の対応をつけた形で付加属性と共にリソ−ス・データベースとして格納する。ここで、リソースファイルとは、一般的には、ソフトウェアと共に論理的に配置される動作のために必要な文字列、アイコンイメージなどの実行不可能なデータ(リソース)を格納したファイルをいう。ここで、メッセージを含む情報を抜き出す際にメッセージキーが利用される。メッセージキーとは、ソフトウェアが表示する各種メッセージを特定するキーとなるもので、通常リソースファイルに含まれるが、リソースファイル名がメッセージキーとなることもある。
(2)障害再現シナリオ、障害報告、スクリーンショットやその他機能に対して、上記(1)で用意されたリソース・データベースを用いてテキスト翻訳や画像情報の翻訳等の処理を行う。各処理機能は、既存の障害管理ツールと有機的に結合する。これにより、ソフトウェアサポート業務におけるデータのやり取りにおいて、適時、情報の言語を切り替えることを可能とする装置、方法、およびプログラムを提供する。

0018

ソフトウェアの多言語サポートのため、JAVA(登録商標)のリソースバンドルのようにソフトウェアと翻訳情報を分離する方法は一般的になっているが、この情報は該当ソフトウェアでの翻訳にのみ用いられている。本発明ではここに格納されている各言語翻訳を抽出し、言語間に対応付けた形で格納する。これにより、ソフトウェアに表示されるメッセージの一覧、およびその正確な多言語表現が、他のソフトウェアから利用可能となる。この方法は該当ソフトウェアのソースコード(ソースコード・ファイル)へアクセスする必要が無い。

0019

障害再現シナリオや、レポート、スクリーンキャプチャ等は、担当者の使用言語により作成・利用される。異なる国籍に情報が渡されるときには、翻訳をする必要があり、ある種の情報は新たな言語環境で再度作成する必要が生じる。本発明では、再現シナリオやスクリーンキャプチャ等に内在する言語固有の情報を、リソースから抽出した情報で動的に置き換える。これにより再度作業を行う手間を軽減するとともに、単一の情報に正確な翻訳を加えた形で切り替えることにより正確な情報伝達を可能とする。

発明の効果

0020

本発明によれば、国際化対応ソフトウェアに備わっている情報を利用して、障害報告作業を自然な形で異なる言語へリレーすることが可能となる。これは従来のソフトウェアや手法、コンピュータ・システム・メンテナンスのサービス手法には備わっていない機能である。多国言語に渡るソウトウェア障害レポートにおいても、障害再現用に多言語を切り替えたマシンを用意しなくとも済み、障害レポート等に含まれる言語依存の部分を一々異なる言語用に新規作成する必要がなくなるようなシステム等を構築できる。本発明により、ソフトウェアの国際化対応に利用される各言語のリソースを利用して、製品に関する情報伝達や障害再現における言語障害を軽減させることができる。

発明を実施するための最良の形態

0021

以下、本発明を代表的な実施形態に則して図を参照しながら説明する。以降の説明では前述のリソース探索部をリソース・クローラ部、画面変換部をスクリーンキャプチャ・トランスレータ部、及び翻訳アダプタ部をトランスレーション・アダプタ部と呼ぶことにする。

0022

図2は、本発明の一つの実施形態として、ソフトウェア障害レポート装置20の機能ブロック図を示したものである。本実施形態におけるソフトウェア障害レポート装置20は、入力データとして、障害レポート21、各言語のリソースファイル22(以下単にリソースファイル22と言う)を扱い、主に、リソース・クローラ部23、リソース・データベース24、スクリーンキャプチャ・トランスレータ部25、トランスレーション・アダプタ部26から構成される。また、既に製品化されている公知の障害管理ツール27を含んでよい。更に、キーボードマウス等の一般的な入力部28a、CRT液晶画面等の出力部28b、イーサーネット(登録商標)アダプタ等を備えた通信部29を含んでよい。また、入出力すべても通信回線を通じて他のシステムとデータ交換を行うようにしてもよい。

0023

上記の構成は、一例を示した過ぎずこれに限定されるものではない。同等な機能を備えたものであれば他の構成であってもよい。以下、本装置の各部についての機能を説明する。

0024

リソース・クローラ部23は、障害時にサポート対象となるソフトウェア・プログラムが持つ翻訳可能な文字列を、そのプログラムを構成するファイル、またはプログラムのソースファイルから抽出する機能を有する。具体的には、以下の機能を持つ。
(1)ソフトウェア・プログラムおよび実行環境から各言語のリソースファイル22を探索する。
(2)各言語のリソースファイル22から各国語のメッセージキーとそれに対応する文字列を抽出、リソース・データベース24に格納する。
(3)ソフトウェア・プログラムのソースファイルが入手可能ならばこれを走査し、付加属性をリソース・データベース24に格納する。ここで付加属性(付加情報)とは、翻訳時に訳文を正しく判断する手がかりを与える属性(情報)を言う。
(4)ソフトウェア・プログラム実行時のウィンドウID、使用ファイル(ソフトウェアが読み込んでいるクラスファイル等)を取得し、付加属性をリソース・データベース24に格納する。

0025

リソース・データベース24は、リソース・クローラ部23によって収集された翻訳文字列を保持するデータベースであり、具体的には以下の情報を保持する。
(1)リソース・クローラ部23が収集した翻訳文字列、および、付加属性を保持する。
(2)システムにおける標準的なボタン、アイコン等の情報を保持する。
(3)一般的なリソースファイルにおける命名規則を保持する。
(4)リソースファイル22の変更履歴を保持する。

0026

トランスレーション・アダプタ部26は、動的翻訳実行時に使用される、障害レポートの翻訳機能、具体的には以下の機能を有する。トランスレーション・アダプタ部26は、レポートの形式テキスト形式画像形式、再現シナリオ・スクリプト形式)ごとに複数存在してもよい。
(1)テキストから翻訳が必要な文字列(原文)を抽出する。
(2)原文から訳文を取得する。
(3)訳文から曖昧性を除去する。ここで曖昧性を除去とは、訳文が一意に定まらない場合に、誤った判断をひきおこさない最も確かな訳文候補選出することをいう。
(4)訳文を元のテキストに埋め込む。

0027

スクリーンキャプチャ・トランスレータ部25は、レポートに画像が含まれる場合、トランスレーション・アダプタ部26または障害管理ツール27から呼ばれ、障害レポートの中に含まれる画像から文字列を切り出す、または、画像に文字列を埋め込む。具体的には以下の機能を有する。
(1)画像(ビットマップ)から、テキスト部分と、それ以外の部分を分離する。
(2)抽出されたテキスト部分は、バイト列に変換する(OCR機能)。
(3)画像に文字列を埋め込む。
(4)画像に含まれるアイコン等を判別する。
また、スクリーンキャプチャ・トランスレータ部25は、オプションとして備えられた翻訳辞書26aを参照して翻訳を行う。翻訳辞書26a自体は、公知の技術を用いてよい。

0028

障害管理ツール27は、障害レポート管理、障害解決状況トラッキング責任担当部門ヘの情報伝達等を総合的にサポートするツールである。図2では簡単化のため、障害管理ツール27がソフトウェア障害レポート装置20に含まれる場合を示しているが、障害管理ツール27は、通信部29を介して通信回線経由中央サーバ等に備えるようにしてもよい。

0029

図3は、本発明の第二の実施形態であるソウトウェア障害レポートシステム30の全体を示す図である。本実施形態においては、前述のソフトウェア障害レポート装置20の主要部である、リソース・クローラ部23、スクリーンキャプチャ・トランスレータ部25、トランスレーション・アダプタ部26を、個別の装置(典型的にはネットワーク38で接続されたクライアント装置サーバ装置)で構成されたコンピュータ・システムとして実現したものである。特に図示していないが、各装置はネットワーク38に接続されたコンピュータで実現できる。この図では、各装置は個別にそれぞれ独立してネットワーク38に接続されたものとして示しているが、典型的には、リソース・データベース34、トランスレーション・アダプタ36、障害管理ツール39は、保守管理部門のセンターサーバ内に装備されることが考えられる。これらのサーバは複数あってよいし、国毎、プロジェクト毎部門毎等の別個のロケーションに個別に備えられてもよい。また、リソース・クローラ32、サポート対象ソフトウェア31、およびソフトウェア毎の各言語リソース33a、33b、33c(リソースファイル)は、解析の便宜のために開発部門やテスト部門のクライアント装置またはサーバ装置に備えられてもよい。各装置の機能については、ソフトウェア障害レポート装置20で説明した各機能部と同等であるので、ここでは説明を省略する。

0030

図4は、障害管理ツール39がサポートする動作ログ画面イメージ、再現スクリプト等の障害管理レポートに含まれる情報が各国の担当部門が希望する言語で(典型的にはリソース・データベースから)取り出される様子を示している。ここでは、ユーザからの障害等を受付けるサポート部門が日本のシステム41にあり、開発部門が英語のシステム44、テスト部門が韓国のシステム43および中国語圏のシステム42にある場合を示している。ただし、障害管理ツール39自体には障害レポートの翻訳機能は備えられていない。また、既に述べたように、障害管理ツールは、CLEARQUEST(登録商標)等の公知の製品を使用することができる。

0031

本明細書では、リソース・クローラ32、リソース・データベース34、スクリーンキャプチャ・トランスレータ35、トランスレーション・アダプタ36、障害管理ツール39等の主要部については、一つの装置内の機能部である場合と、別々のサーバ装置内の機能である場合と、および方法の各ステップを表す場合とがある。従って、特に区別する必要がない限り、以下、単にリソース・クローラ等のように符号番号を省略して表記することにする。続いて各部の処理を更に、詳しく説明する。

0032

図5は、リソース・クローラとリソース・データベースの概念図を示す図である。リソース・クローラは、サポート対象ソフトウェア、OS(オペレーティング・システム)やJAVA(登録商標)等の実行環境の各言語のリソースファイルを探索する。各言語リソースには、言語毎にメッセージキーとそれに対応する文字列を保持している。リソース・クローラは、リソース・データベースにメッセージキーを元に各言語の対応をつけた表を作成する。

0033

図6は、リソース・クローラの処理フローを示す図である。まず、ステップS800において、リソースファイルを探索する。次にステップS801において、可読形式(すなわち圧縮されたファイルやバイナリ形式でない)であるかどうかを判断し、可読形式でなければ、解凍等必要な処理を行い可読形式に変換する(ステップS802)。可読形式であれば、ステップS803においてリソースファイルから各国語メッセージを抽出する。更にステップS804において、メッセージをDB(リソース・データベース)に登録する。次にステップS805において、付加属性を取得可能かどうか判断し、付加属性が取得可能であれば、付加属性をDBに登録してステップS807へ進む(ステップS806)。付加属性が取得可能でなければ、他のリソースファイルが存在するかどうかを判断し(ステップS807)、他のリソースファイルについてステップS801〜S806の処理を繰り返す。次に、ステップS808において、ソースファイルが参照可能かどうかを判断し、参照可能であればソースファイルから付加属性を抽出し、DBに登録してステップS811に進む(ステップS809、S810)。ソースファイルに対する処理が終わった後、ステップS811では、ソフトウェアを実行して更に付加属性を取得できるかを判断する。最後に、付加属性が取得可能な場合は、対象ソフトウェアを実行して実行情報から付加属性を抽出し、DBに登録して全ての処理を終了する(ステップS812〜S814)。

0034

図7は、スクリーンキャプチャ・トランスレータの処理の流れを示す図である。この図で示すように、スクリーンキャプチャ・トランスレータは、障害時に表示されたメッセージ画面パネル50)を解析し、翻訳すべき文字列のみを各国語に翻訳し、更に、元の画面イメージに埋め込む機能を有する。ここでは、画面57が英語、画面58がドイツ語、画面59が韓国語に翻訳されて出力された例を示している。

0035

図8は、図7の処理を更に詳しく説明したものである。すなわち、処理すべきパネル50をフォント・データ51から得られるフォントパターンから画像と文字を分離する。パネルに表示される文字はおおよそ決まっているのであらかじめ使用される頻度が高い文字等は登録しておくことでフォントパターンの比較が効率化される。ここで、OCR(Optical Code Reader)等の公知の文字認識技術を利用してよい。パネル50から文字と画像が分離された結果、空白画像51と文字部52のようになる。文字部52には、リソース・データベースを参照して(リソース・データベースにない場合は、公知の翻訳辞書を用いて)他の言語53〜55に翻訳する。

0036

ここで、ソフトウェアのコードやバイナリ実行ファイル圧縮ファイル等はバイナリ形式で提供されることも多い)から直接文字列を抽出することで翻訳の精度を飛躍的に向上させることができる。これは、文単位の比較(リソース・データベースを用いて)による翻訳なので、単語や形態素解析に依存する曖昧性がないこと、同一パネルから複数の文字列を抽出することで翻訳対象のパネルを的確に特定できること、によるものである。また、パネルに使用されているアイコン情報もメッセージの種類とパネルを特定するための有力な情報となる。

0037

最後に、翻訳された空白画像56と翻訳済み文字列53〜55から各言語用の画像を作成する。以上の結果、57〜59のような画面データが得られる。ここで、翻訳後の文字列が画像に収まらないような場合は、更に次のような調整を自動的に行うこともできる。
(1)文字列を折り返す。
(2)文字列のフォントを小さくする。
(3)画像を拡大する。
また、言語によっては(アラビア語のように)文字列を右から左に書くものもあり、その場合が画像を左右反転させた後、文字列を埋め込むことも可能である。

0038

図9は、スクリーンキャプチャ・トランスレータが文字列を抽出する際の、別の例を示したものである。ここでは障害時の初期画面91(ここではダイアログを例にする)がある場合、次の情報を用いて、文字列部分を分離する。
a)ダイアログの既定色情報
b)ダイアログの既定フォント情報
ただし,ダイアログの色とフォントの情報は,既定値と異なる場合もあるので,次の方法も活用する。
c)OSに存在するフォントから適当な文字を選びパターンを比較する。
物の画像が日本語の場合、ひらがなや句読点等の使用頻度の高い文字が効率的である。これは、言語ごとに最適化された文字を選ぶ。
d)輝度彩度等の色調情報を活用して、輝度や彩度が離れている色の組み合わせから、ダイアログの背景色文字色を推測する。
文字列を抽出する過程をイメージにすると図中の92のようになり、6組の文字が抽出できる。画像だけのデータ93も保持する。

0039

図10は、トランスレーション・アダプタと、他との関係を示す図である。既に説明したように、トランスレーション・アダプタは、翻訳すべき再現シナリオ・スクリプト37a、テキスト形式レポート37b、及び画像形式レポート37cを入力データとする。このうち画像形式レポート37cは、そのままスクリーンキャプチャ・トランスレータに引き渡してもよいし、トランスレーション・アダプタからスクリーンキャプチャ・トランスレータを呼び出す形にしてもよい。

0040

図11は、トランスレーション・アダプタに対する再現シナリオ・スクリプトの簡単な例を示す図である。オリジナルの再現シナリオ・スクリプトに含まれる翻訳すべき文字列のあるフィールド60〜62を、スクリプト構文にしたがって識別し、リソース・データベース上の各言語の対応表63を参照して、翻訳すべき文字列と指定の言語の翻訳後の文字列を抽出する。抽出して翻訳された文字列は64〜66に示すように再現シナリオ・スクリプトに埋め込まれる。

0041

図12図17は、以上説明した、障害発生でユーザサポートが行う行為、リソース・クローラ、リソース・データベース、及びスクリーンキャプチャ・トランスレータの一連動きをまとめたものである。以下、一部重複になるが簡単に説明する。

0042

図12は、障害発生時の、典型的にはサポート部門の報告者が行う、障害パネル(障害発生時に、障害を示す情報を切り取ったもの、多くの場合、障害ウィンドウや障害ダイアログボックスが該当する)作成の処理フローを示す図である。多くの場合、障害発生時(ステップS111)に、スクリーンキャプチャ(スクリーンショット)を行い(ステップS112)、障害パネルを作成する(ステップS113)必要がある。

0043

図13は、リソース・クローラが行うリソース・データベース34の作成処理フローを示す図である。OS依存言語情報130、JAVA(登録商標)言語依存情報131、アプリケーション言語依存情報132はリソースファイルの一例である。図示するように、リソース・クローラは該当ソフトウェアの全てのサポートしている言語についてリソースファイルを探索し、翻訳に有用な情報をリソース・データベース34に蓄積する。詳細については、図6を参照。

0044

図14は、障害パネルの分類の処理フローを示す図である。ここでは障害レポートが画像データの場合を想定している。まず、対象画面のタイトル(パネル・タイトル)を判別し(ステップS131)、パネル・タイトルがない場合は、未登録のパネルであると判断して、未登録パネルの翻訳へ処理を渡す(ステップS134)。パネル・タイトルがある場合は、画像から文字列抽出サブルーチンを呼び出し(ステップS160)、文字列をここで実際に抽出する。パネル・タイトル、及び抽出された文字列からリソース・データベース34を参照して既に障害パネルが登録されているかを判断する(ステップS132)。障害パネルが登録されていれば、登録パネルの翻訳処理(ステップS133)へと処理を移す。

0045

図15は、登録パネルの翻訳の処理フローを示す図であり、図16は、未登録パネルの翻訳の処理フローを示す図である。登録パネル処理と未登録パネル処理共に、対象とする障害パネル34aから翻訳すべき文字列をステップS160において抽出するまでは共通である。登録パネルの場合は、リソース・データベース34を参照して文字列の翻訳を効率的に行えるが、未登録パネルの場合は、リソース・データベース34に必要な情報がないので、公知の翻訳辞書を備えた翻訳サーバを呼び出し(ステップS151)、必要な翻訳を行う。その後、翻訳された文字列の画像への埋め込みの処理については、共通である。

0046

図17は、文字列抽出サブルーチン(ステップS160)の処理フローを示す図である。文字列抽出サブルーチンは、スクリーンキャプチャ・トランスレータの中核をなす部分である。この処理は既に概略は説明済みであるが更に、詳しく説明すると、ステップS161において文字列の色調を推測し、ステップS162において、フォント・データ51を参照して特定色調とフォント(パターン)を照合し、文字列抽出ができるかを判断する。この判断がYesの場合は、文字列を抽出する(ステップS164)。この判断がNoの場合は、予め試行錯誤トライアル回数を定めておき、その試行回数までは色調データ推測条件等を変化させてステップS161、S162を繰り返す。試行回数を超えた場合は、文字列の抽出ができないと判断し、エラー用代替文字列を出力する(ステップS165)。

0047

<1.方法の概要
図18は、本発明の他の実施形態としてのソフトウェア障害レポート方法について概要をまとめたものである。すなわち、本実施形態では、以下の4つの処理を行う。
(1)原本となる障害レポートを取得する(ステップS181)。
登録されている障害レポートを取り出す。
(2)テキストデータから翻訳が必要な部分を抽出する。
また、画像データから文字部分を認識、文字列を抽出。文字列を除く画像部
分を抽出する(ステップS182)。
(3)原文と訳文の対応関係取得する(ステップS183)。
すなわち、ユーザの望む言語への訳文を取得する。
(4)訳文による障害レポートを作成する(ステップS184)。
すなわち、(2)で切り出された部分に適当な訳文を挿入する。(2)で作成され
た画像に訳文を埋め込み、画像を再構成する。

0048

以下、上記の(1)〜(4)のステップについて更に説明する。
(1)訳文を得るまでの流れ
大きく分けて、次の3つの流れがある。
1)一致する候補がない。
2)一致する候補が一つだけ存在する(訳が一意に決定できる)。
3)一致する候補が複数存在する。
ここで言う「候補」とは、「リソース・データベースに格納されている、原文と同じ言語の文字列」で、検索時に見つかる文字列のことを指す。

0049

図19にこの処理フローを示した。ステップS191において、リソース・データベースから候補を取得する。次に、ステップS192において、完全一致候補があるかどうか判断する。Noの場合は、ステップS193において、複合文処理、変数部分処理を行い、その後ステップS191に戻る。ステップS192においてYesの場合は、その完全一致候補が複数あるかを判断し(ステップS194)、複数あれば、ステップS195において、追加情報を用いて候補の絞込みを行い、ステップS196に処理を移す。また、ステップS194でNoの場合も同様にステップS196に処理が移り、候補に対応する訳文でユーザが望む言語のものを取得する。

0050

(2)訳が必要となる原文の切り出し
画面の場合は、例えば、スクリーンキャプチャ・トランスレータのような方法を用いて、画面から文字列と画面を分離する。分離された文字列が原文となる(図20参照)。テキスト形式の場合は、例えばトランスレーション・アダプタのような方法を用いて、翻訳が必要な文字列とそれ以外を分離する(図21参照)。

0051

(3)原文と訳文の対応関係取得
1)与えられた原文と完全一致する文字列をリソース・データベースから検索する。
2)一致する文字列を発見した場合には、それに対応する求める言語の訳文を取得する。
3)一致する文字列が複数あり、それに対応する訳文が異なる場合には、曖昧性除去処理を行う。

0052

(単一一致の例)
図22(a)に示すようなリソース・データベース内のデータから日本語の「警告形式のウィンドウ」を検索する。
一致した文字列が発見されたので、対応する訳文を取得する。例えば、英語の場合「警告形式のウィンドウ」→「Warning Window」と翻訳する。

0053

(複数一致の例)
図22(b)に示すようなリソース・データベース内のデータから日本語の「エラーが起きました。」を検索する。
一致した文字列が発見されたので、対応する訳文を取得する。例えば英語の場合
「エラーが起きました。」→「Error happened.」、 「Error occurred.」と二つとなる。
また、一致する文字列が複数あり、それに対応する訳文が異なるので、曖昧性除去処理を行う。詳しくは後述の、(2−3)訳文の候補が複数存在する場合を参照されたい。

0054

一致する文字列が発見できない場合は、原文が複数の文字列から構成されている可能性や、動的に与えられる文字列が組み込まれている可能性が高い。原文を分割、変数部分を除いて文字列を検索することにより、訳文を取得する。詳しくは、後述の、(2−2)訳文の候補が存在しない場合を参照されたい。
(4)訳文による障害レポートの作成
画面の場合は、得られた訳文と画面を再構成する(図23参照)。
テキスト形式の場合は、得られた訳文を翻訳が必要な場所に挿入する(図24参照)。

0055

<2.訳文を得る流れの詳細>
以下、訳文を得る流れについて詳細に説明する。

0056

(2−1)訳文の候補が一つだけ存在する場合
原文に一致するものがリソース・データベース中に一つしか存在しない場合、それに対する訳文は一意に定まる。図25にこの処理フローを示した。ステップS251において、リソース・データベースから訳文の候補を取得する。次にステップS252において、取得した候補と原文が完全一致でかつ唯一である場合(ステップS254:Yes)、候補に対応する利用者が求める言語の訳文を取得する(ステップS254)。ステップS252がNoの場合は、複合文・変数部分処理や候補の絞込み(ステップS253)を行う。
(2−2)訳文の候補が存在しない場合
リソース・データベースはアプリケーションにおいて表示されるメッセージ等の情報をすべて持つが、その中に原文と一致する文字列が存在しない場合には、原文が複数の文字列から構成されている可能性がある。すなわち以下の二つの場合がある。
1)原文が一つの文章ではなく、複数文字列の組み合わせからできている場合
2)原文の中に、動的に与えられる文字列が組み込まれている場合
これらの場合には、文の境界で分割することや、変数部分を別に切り出すことで、一致する訳文を探すことができる。

0057

図26にこの処理フローを示す。ステップS261において、リソース・データベースから変数を含む候補を取得する。変数以外が一致する場合(ステップS262:Yes)、変数部分を切り出し(ステップS263)、終了する。変数以外が一致しない場合(ステップS262:No)、境界があるかどうかを判断し、ある場合は(ステップS264:Yes)、ステップS265において境界を分割して終了する。境界がない場合は(ステップS264:No)、そのまま終了する。

0058

1)の場合:
文字列の境界を認識し、文字列を分割する。文字列の境界は改行スペース、句読点等の情報を利用することにより認識することが出来る。また形態素解析を用いると、意味のある単位での文字列の分割が可能である。

0059

2)の場合:
リソース・データベースに変数を含む文字列が存在する場合、その変数部分を除いて一致する文章を取得する。また変数部分に対応する訳文がリソース・データベースから出来る場合は、得られた文章に挿入する。

0060

(2−3)訳文の候補が複数存在する場合
一つの翻訳対象文に対し複数の翻訳候補文がリソース・データベースに存在する場合がある。例えば、「エラーが起きました。」といった比較的単純な文の場合、訳文の候補として、「Error occured.」や「Error happened.」等、複数存在する場合が考えられる。そこで、どの訳文を採用するかを決定する必要がある。その判断においては、該当文が「どの“文脈”により表示されたか」が重要な手がかりとなる。訳文を正しく選択する手がかりを与える属性をここでは、付加属性と呼んでいる。付加属性を用いれば翻訳の精度を向上させることができる。

0061

ソフトウェア・プログラムにおいて、文字列への付加属性は数多く考えられる。適切な訳文選択のための、精度の高い情報を与えるものとして以下のようなものが考えられる。それぞれ、次のような情報を提供する。
1)ウィンドウタイプ
a)「警告」、「エラー」、「情報」といった、メッセージの趣旨
b)「YES/NO」、「OK」等、どのようなレスポンスが求められるか
c)ウィンドウID
d)どういう処理シーケンスで表示されたメッセージ
e)その文字列はどのウィンドウに所属するか
f)所属するウィンドウの親子関係
2)命名規則
g)メッセージの趣旨
h)出現場所カテゴリー
i)メッセージが存在するクラス名
3)画面情報
j)メッセージの趣旨
k)どのようなレスポンスが求められているか
l)ボタン、メニュー、メッセージ文といったメッセージの出現場所のカテゴリー

0062

これら付加属性は、それぞれ単独で用いてもよいし、併用してもよい。以下、これらの各付加属性については、実施例1〜3として説明する。

0063

[ウィンドウタイプを付加属性とする方法]
通常、ソフトウェア・プログラムでは、メッセージウィンドウは、ソフトウェアプログラマーが、初めからプログラミングするのではなく、既存のカスタムウィンドウを用いる。カスタムウィンドウは、OSが初めから備えているもので、それを使用したい場合、プログラマーは、ウィンドウのタイトルと、メッセージ文、ウィンドウのタイプを指定するだけでよい。このことは、C/C++、JAVA(登録商標)、VISUABASIC(登録商標)等、GUIを備えたプログラムを作成するプログラミング言語に共通に当てはまる

0064

<リソース・クローラが走査する情報>
リソース・クローラは、ウィンドウタイプを取得するために、プログラムのソースコードを走査する。以下では、簡単のため、VISUALBASIC(登録商標)を用いたプログラムサンプル図27に示す。関数MsgBoxは、メッセージウィンドウを表示し、引数1は、メッセージ文、引数2は、メッセージウィンドウのタイプ、引数3は、メッセージウィンドウのタイトルである。なお、このプログラムは、コマンドプロンプトより、cscript messages.vbsとタイプすることにより動作させることができる。

0065

上記のプログラムを実行すると、図28のようなメッセージウィンドウが表示される。メッセージウィンドウのタイプにより、そのメッセージが「重大エラー」として発せられ、その対応としては「OK」ボタンしか押せないもの(281)、そのメッセージが「警告」として発せられ、その対応としては「OK」ボタンしか押せないもの(282)、そのメッセージに対し、「はい」、「いいえ」で答えるもの(283)、複数のアクションを選択できるもの(284)といった形で、メッセージウィンドウタイプは、多くの情報を保持する。メッセージウィンドウタイプは、十数個存在し、かつ、応答ボタンとの組み合わせを考慮すると数十となる。従って、訳文を一意に決定するための重要な付加属性とすることができる。

0066

<リソース・クローラの実装法>
メッセージ画面を表示するAPIは、非常に限定的であるので、リソース・クローラは、簡単なテキスト処理を行うプログラムによって実現できる。具体的には、正規表現関数を用いた、シェルスクリプト等で実装できる。ここで、正規表現関数とは、必要とする文字列のみをテキストファイルから抽出するために利用できるパターン処理関数群である。上述のVisualBasic(登録商標)プログラム例では、“MsgBox”が出現する行から、ダブルオート(“)で囲われた文字列、および、ウィンドウタイプとして、vbXXX(ウィンドウタイプの書式)で始まる文字列を抽出するという処理により実装できる。

0067

<リソース・データベース>
リソース・データベースは、メッセージウィンドウタイプ、および、そのメッセージウィンドウのタイトルを含む。図29は、メッセージタイプを保持したリソース・データベースの例を示したものである。

0068

<翻訳決定アルゴリズム
「エラーが起きました。」というメッセージが障害レポート内にあるとする。そして、そのメッセージを表示するメッセージウィンドウのタイプ、および、ダイアログタイトルが、それぞれ、vbExclamation、「警告形式のウィンドウ」とすると、訳文は「Error happened.」と決定することができる。

0069

障害レポートからメッセージウィンドウタイプとダイアログタイトルは以下のように判定する。以下の2パターンが考えられる。

0070

障害報告レポートがテキストで記述されている場合:ダイアログのタイトルが記述されているため、それを元に翻訳を決定する。またレポート中の「警告」「情報」等のキーワードからも、メッセージウィンドウタイプがわかる。

0071

スクリーンキャプチャで障害報告がされている場合:画面に現れるメッセージの他に、画像が持つ文字以外の部分から付加属性を取り出し利用する。詳しくは、後述の実施例3で示す[補足:スクリーンキャプチャ・トランスレータからのアイコン抽出]を参照されたい。

0072

[ウィンドウIDを付加属性とする方法]
ここでは、翻訳文字列をウィンドウIDと関連付けると、訳文の選択を正しく行えることを示す。まず、図30のダイアログ・ウィンドウを例にとる。

0073

このダイアログ・ウィンドウは、テキストラベル入力フィールド、ボタン等によって構成されている。プログラム内部では、これら全ての構成要素には、固有のIDが割り振られており、プログラムは、このIDを手がかりに構成要素を識別する。例えば、ユーザがこのダイアログ・ウィンドウに対して行った処理は、イベントとしてプログラムに渡される。「実行」ボタンがクリックされた場合を例にとる。実行ボタンにID番号100が割り振られていたとすると、「要素100上でクリックボタンが押された」というメッセージがオペレーティング・システムから飛ばされる。その際の処理は、プログラムコード内に(Case文等で)定義する。つまり、このID番号は、完全な精度で要素を特定する手段といえる。

0074

<リソース・クローラが走査する情報>
図31は、Windows(登録商標)オペレーティング・システム上のプログラムで、ダイアログ・ウィンドウの形状、および、それを構成する構成要素のIDを定義しているリソースファイルと呼ばれるソースコード(sample.rc)の一部を示したものである。

0075

先頭行のLANGUAGE宣言311は、以下の定義がどの言語用かを示す。それに続く#define宣言312が、構成要素のIDを定義する。そして、構成要素の文字列とIDとの関連付け等の情報が以下に続く。
DD_TESTDIALOGEX 22,17,257,130———313
CAPTION “win32アプリケーションテスト” ———314
は、このダイアログ・ウィンドウ自体のID、および、ダイアログタイトル(“win32アプリケーションテスト”)である。(#define宣言より、IDD_TESTが100とされていることから)IDは100とわかる。(続く数字は、ウィンドウの配置であり、座標(22、17)を起点とし、横長257、縦長130であることを示す。)そして、BEGIN315以下のステートメントは、そのダイアログ・ウィンドウ上の構成要素上の文字列とIDの関連付け等を示す。

0076

例えば、LTEXT “データ(&D):”、IDC_STATIC_1、6、9、50、8は、”データ(&D)”という文字列は、ID番号は102であることを示す。

0077

<リソース・クローラの実装法>
プログラムソースにアクセスできる場合:
リソース・クローラは、上述のファイルを走査し、リソース・データベースを作成することになる。その流れは以下のようになる。
1)LANGUAGE宣言を発見し、言語をリソース・データベースに保管する。
2)ダイアログ・ウィンドウのIDおよび、タイトル文列を保管する。
3)各構成要素のID、および、関連付けされた文字列を保管する。

0078

これは、簡単なテキスト処理を行うプログラムによって実現できる。具体的には、正規表現関数を用いた、シェルスクリプト等で実装できる。正規表現関数は、必要とする文字列のみをテキストファイルから抽出するために利用できるパターン処理関数である。

0079

プログラムソースにアクセスできない場合:
リソース・データベースは、ソースコードに直接アクセスした場合のほうが、より容易に作成できるため、(障害レポートの)対象となるソフトウェア・プログラムの開発者によって提供されることを想定している。しかし、ソースコードへのアクセスができない状況、つまり、実行形式(バイナリ形式)のみで提供されたプログラムにおいても、ウィンドウID、文字列を取得することが可能である。

0080

<リソース・データベース>
リソース・データベースに保管されたデータは、図32に示すウィンドウIDを保持したリソース・データベースで整理される。各文字列の対訳に加えて(ウィンドウ)ID330、および、親(ウィンドウ)ID331が保管されている。例えば、「データ」および「フォルダ」は、ウィンドウIDが100であるウィンドウ・タイトル「Win32アプリケーション」というウィンドウに所属することがわかる。この情報保持方法により、階層構造になった構成要素もチェーン形式で紐付けがわかる。

0081

<翻訳決定アルゴリズム>
通常、障害レポートは、メニュー選択→表示画面→画面上での処理、といった一連の操作によって説明される。たとえば、「ファイル選択」画面より、「選択」ボタンを押す。従って、同じウィンドウに所属する翻訳文字列が近傍に出現するのが通常である。従って、近傍の例えば、数個の翻訳をバッファリングしておき、翻訳候補が複数存在する場合、共通の親IDに属する翻訳文字列を優先して選択することにより翻訳精度を高めることができる。

0082

ファイル構造・メッセージキーを付加属性とする方法]
リソースファイルは、プログラム実行時に挿入されるメッセージとメッセージを一意にあらわすメッセージキーの組み合わせを保持している。リソースファイルは一定の規則に沿ってファイルに梱包されている。配置されるファイル構造も規則に沿ったものである。またメッセージキーの命名にも規則性が容易に見つけられる。これらリソースファイルに関する陰的陽的な規則を利用し、付加属性とする。

0083

<リソース・クローラが走査する情報>
リソース・クローラは、アプリケーション本体および実行環境で取得できるリソースファイルを探索し、リソースファイルから各国語のメッセージを抽出し、データベースに格納する。その際、対象文だけではなく、メッセージキーや文を取得したファイル名、ファイル構造等から取得可能な情報もあわせて格納する。

0084

図33に、JAVA(登録商標)が保持するプロパティ・リソースファイルの例を示す。プロパティ・リソースファイルはjarファイル(プログラムを構成する実行ファイルを圧縮したもの)に梱包されているか、フォルダの中に格納されている。jarファイル等に梱包されている場合には、これを展開する。このとき、このプロパティファイルが存在するディレクトリ構造ディレクトリ名、またjarファイル内の構造を取得する。

0085

これらの情報は、このメッセージを出力するアプリケーションの名前、関連するクラス名、またバージョン番号等を含んでおり、それらを付加属性とする。またメッセージに対応するメッセージキーも取得し、同一のメッセージキーで同様の付加属性を持つものを組とする。

0086

<リソース・クローラの実装法>
リソース・クローラは、アプリケーションや実行環境で取得できるリソースファイルを探索する。またこの際にjarファイルのような圧縮形式の場合にはこれを展開し、中身を走査する。バイナリ形式のものである場合には、可読な形式に変換する。この仕組みはウイルススキャナやOSに付随するファイル検索機能と同等のもので実現できる。リソースファイルは、一定の書式に従って記述されているため、簡単な正規表現処理を用いることにより、メッセージやキー、また付加属性を抽出することができる。それらをデータベースに格納する。

0087

<リソース・データベース>
リソース・データベースには図34で示すようにメッセージキー(messagekey)350と付加属性351〜353(class name,Version,folder)が、整理されて格納される。各国語メッセージは同一行に保持される。

0088

<翻訳決定アルゴリズム>
中止」という「ボタン」が現れたとする。これに対する英語訳文の候補としては、リソース・データベースからは「Abort」と「Break」の両方が取得される。この場合、付加属性を利用し、どちらの訳文がふさわしいか決定する。

0089

メッセージキーの命名規則を用いる場合:
メッセージキーには、暗黙、明示ともに命名規則が適応されるのが普通である。この規則を用いて、メッセージキーからそのメッセージの利用箇所や状態にあたる情報を得る。「中止」の例では規則から、片方はボタンの名前、片方はウインドウメニューの項目と判断し、「Abort」を英語訳文の候補とする。命名規則はそのプロダクトプロジェクトに応じて定められているため、一般的な命名規則に即したものは容易に対応できる。製品ごとに、一定のルールを規定することで精度を高めることもできる。

0090

クラス名やフォルダ名を用いる場合:
アプリケーションのプロセスIDや、プロセスが利用しているファイル名は、公知のツールを用いて取得することができる。この情報とリソース・データベースが持つクラス名、フォルダ名を照合することにより、最も確かな候補を選出する。

0091

許諾可能文字列を選択する場合:
もし確率の高い候補が絞り込めなかった場合には、その両方を併記することが許容されるかどうかを確認する。再現シナリオ・スクリプトでは自動実行においても失敗がないと判断できる場合、両方を並列表記し、スクリプト実行時に自動判断する。例えば、同一画面にbreak、abort両方の候補が出現しないことが(他メッセージやボタンの翻訳の結果)確認できる場合には、button[Abort:Break]と並列表記することにより、スクリプトの実行を可能とする。

0092

[補足:スクリーンキャプチャからのアイコン抽出]
ソフトウェアが表示するメッセージ、特にユーザに注意の喚起を行うメッセージ画面においては、システム特有の状態を表すアイコンが表示される。図35にそのアイコンが表示された画面例371〜374を示す。これらのアイコンはそのウィンドウが発するメッセージの性質を現すもので、訳文を一意に決定する付加属性とすることができる。また、その画面に存在する、入力部、ボタンの数等の情報も他の情報と紐付けることにより付加属性となりうる。また、アイコンは国ごとに異なることもあるので、訳文決定の際にアイコン自体をその国に適したものに変更することもある。

0093

<スクリーンキャプチャ・トランスレータでの実装>
画面に現れるアイコン、ボタン等の表示はシステムによって標準化されているものが多い。そのためシステム標準のアイコンをあらかじめリソース・データベースに保持しておくことにより、簡単なパターンマッチングにより、画面上に現れている情報の性質、求められているアクションの種別等が高い精度で得られる。ここで、パターンマッチングとは、入力画像の中にあらかじめ標準パターンと同じものがあるか、あるいは近いものがあるかを検出することをいう。また、あらかじめ用意した標準パターンをテンプレートと呼び、入力画像にテンプレートを重ねながら移動し、2つの画像が画素データレベル対応の相関を調べることをテンプレートマッチングという。

0094

以上、本発明を実施形態、および実施例を用いて説明したが、本発明の技術的範囲は上記実施形態に記載の範囲に限定されない。上記実施形態に多様な変更または改良を加えることが可能である。また、そのような変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

0095

本発明における一つの実施形態として説明したソフトウェア障害レポート装置20、またはその機能は、コンピュータ上のシステムまたはコンピュータにその機能を実行させるコンピュータ・プログラムによって実現可能である。コンピュータ・プログラムはそれを格納したコンピュータ可読の記録媒体としても提供され得る。媒体は、電子的、磁気的、光学的、電磁的赤外線または半導体システム(または、装置または機器)あるいは伝搬媒体であることができる。コンピュータ可読の記録媒体の例には、半導体またはソリッドステート記憶装置磁気テープ、取り外し可能なコンピュータ可読の媒体の例には、半導体またはソリッド・ステート記憶装置、磁気テープ、取り外し可能なコンピュータ・ディスケットランダム・アクセス・メモリ(RAM)、リードオンリー・メモリ(ROM)、リジッド磁気ディスクおよび光ディスクが含まれる。現時点における光ディスクの例には、コンパクトディスク−リードオンリー・メモリ(CD−ROM)、コンパクト・ディスク−リード/ライト(CD−R/W)およびDVDが含まれる。

図面の簡単な説明

0096

本発明の課題に係るソフトウェア障害レポートの典型例を示す図である。
本発明の一つの実施形態であるソウトウェア障害レポート装置の機能ブロックを示す図である。
本発明の他の実施形態であるソウトウェア障害レポートシステムの概要を示す図である。
障害管理ツールを経由して翻訳された様々な情報レポートを各担当部署が得られる様子を示した図である。
リソース・クローラとリソース・データベースの概念図である。
リソース・クローラの処理フローを示す図である。
スクリーンキャプチャ・トランスレータの処理の概念図である。
スクリーンキャプチャ・トランスレータの処理のフローを示す図である。
スクリーンキャプチャ・トランスレータによる画像と文字列とを分離を示す図である。
トランスレーション・アダプタの概念図である。
再現シナリオ・スクリプトの簡単な一例を示す図である。
障害パネルの作成処理フローを示す図である。
リソース・データベースの作成処理フローを示す図である。
障害パネルの分類の処理フローを示す図である。
登録パネルの翻訳の処理フローを示す図である。
未登録パネルの翻訳の処理フローを示す図である。
文字列抽出サブルーチンの処理フローを示す図である。
ソフトウェア障害レポート方法の簡単な処理フローを示す図である。
訳文を得るまでの流れを示す図である。
画面形式の場合の訳文が必要となる原文の切り出しを示す図である。
テキスト形式の場合の訳文が必要となる原文の切り出しを示す図である。
原文と訳文の対応関係取得を示す図である。
画面形式の場合の訳文による障害レポートの作成を示す図である。
テキスト形式の場合の訳文による障害レポートの作成を示す図である。
訳文の候補が一つだけ存在する場合の訳文を得る処理フローを示す図である。
訳文の候補が存在しない場合の訳文を得る処理フローを示す図である。
リソース・クローラが走査するプログラムのソースコードの例を示す図である。
図27のプログラムを実行した際のメッセージウィンドウの例を示す図である。
メッセージタイプを保持したリソース・データベースを示す図である。
ダイアログ・ウィンドウの例を示す図である。
ダイアログ・ウィンドウの形状、およびそれを構成する構成要素のIDを定義するソースコードの一部を示す図である。
ウィンドウIDを保持したリソース・データベースを示す図である。
JAVA(登録商標)が保持するプロパティ・リソースファイルの例を示す図である。
メッセージキーと付加属性が格納されたリソース・データベースを示す図である。
ユーザに注意の喚起を行うメッセージ画面におけるシステム特有の状態を表すアイコンを示す図である。

符号の説明

0097

10障害レポートの典型例と課題
20ソフトウェア障害レポート装置
21 障害レポート
22リソースファイル
23リソース・クローラ部
24 リソース・データベース
25スクリーンキャプチャ・トランスレータ部
26トランスレーション・アダプタ部
27障害管理ツール
28a 入力部
28b 出力部
29通信部
31サポート対象ソフトウェア
32 リソース・クローラ
33a、33b、33c 各言語リソース
34 リソース・データベース
34a障害パネル
35 スクリーンキャプチャ・トランスレータ
36 トランスレーション・アダプタ
37a再現シナリオ・スクリプト
37bテキスト形式レポート
37c画像形式レポート
39 障害管理ツール
41サポート
42、43テスター
44開発者
50 パネル
51フォント・データ
56空白画面
57、58、59翻訳後画面
130 OS依存言語情報
131 JAVA(登録商標)言語依存情報
132アプリケーション言語依存情報

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

新着 最近 公開された関連が強い 技術

この 技術と関連性が強い 技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する挑戦したい社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ