(57)【要約】      （修正有）【課題】エラー要因を容易に推定することができるアプリケーション開発におけるエラー処理方法の提供。【解決手段】エラー発生によって例外処理が生じ、該例外処理の例外名とエラー詳細コードとを発生するエラー処理方法において、例外処理が発生した場合、前記エラーにる例外名をキーとして単一要因データベース２５０を検索して障害要因を検索し、該検索により障害要因が検索できない場合、前記エラーによるエラー詳細コードをキーとして詳細コード別障害要因辞書２４０を検索し、これにより検索した障害要因と前記クラス別機能クラス−障害要因辞書２３０に格納した全オブジェクトに含まれるクラスとを比較して障害要因を推定するもの。【選択図】  図３
2004287700.tif 000002
【特許請求の範囲】
【請求項１】
エラー発生によって例外処理が生じ、該例外処理の例外名とエラー詳細コードとを発生するオブジェクト指向言語でのアプリケーション開発におけるエラー処理方法であって、エラー発生時の例外名と該例外名に対応する障害要因との対応を格納した単一要因データベースと、エラー発生時のエラー詳細コードと該エラー詳細コードに対応する障害要因との対応を格納した詳細コード別障害要因辞書と、エラー発生までの開始メッセージを登録しているが終了メッセージを受けていない全オブジェクトのクラスの状態を格納したクラス別障害可能性データを格納したクラス別機能クラス−障害要因辞書とを設け、前記例外処理が発生した場合、前記エラーによって発生した例外名をキーとして単一要因データベースを検索して障害要因を検索する第１ステップと、該第１ステップにより障害要因が検索できない場合、前記エラーによって発生したエラー詳細コードをキーとして詳細コード別障害要因辞書を検索する第２ステップと、該第２ステップにより検索した障害要因と前記クラス別機能クラス−障害要因辞書に格納した全オブジェクトに含まれるクラスとを比較して障害要因を検出する第３ステップとを実行することによって、エラー要因を推定することを特徴とするオブジェクト指向言語でのアプリケーション開発におけるエラー処理方法。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は、業務用コンピュータシステム開発におけるエラー要因を推定し、システム運用時に個々の業務システム特有にありがちな障害切り分けが不要なオブジェクト指向言語でのアプリケーション開発におけるエラー処理方法に関する。
【０００２】
【従来の技術】
一般に業務用コンピュータシステム開発においては、システム開発における機能分割法として、８０〜９０年代に使われた構造型システム開発では、処理をいくつかのパターンに分けて用意し、単純な機能を持った部品を使いながらパターン中に用意された箇所に業務処理独特の部分のコードを作成する事で処理機能を実現する手法や、オブジェクト指向開発で使われるフレームワーク形態のシステム開発では、処理機能をいくつかのパターンに分けて用意しておきフレームワークとすると共に単純な機能を持つクラスと呼ばれる単位の処理機能に分割し、フレームワークから必要なクラスを役割に応じて呼び出す形で処理を進める手法が採用されていた。
【０００３】
この業務用コンピュータシステム開発過程において例外処理が発生することがあり、この例外処理とは、主として応用プログラムで処理を実行している最中に処理続行に不都合な状態が発生する事等により本来の目的に到らずに予想外（例外）の事態に対応する事や当該対応処理の事を言い、この原因としては、エラー／障害の発生や、応用プログラムの扱うデータにおいて前提条件外の物が入力された事が考えられる。
【０００４】
従来技術による前記例外処理方法は、例えばオブジェクト指向開発において例外処理も一つの特化した機能クラスとして認識する手法が採用され、具体的には、▲１▼エラーの発生によって制御を例外処理に移行し、該例外処理が当該エラーの内容／エラー発生した時のデータ／エラー発生部位等のエラー発生の要因を調査する情報を応用プログラムから収集し、▲２▼前記▲１▼によって収集されたエラー情報をオペレータに表示し、▲３▼処理全体をロールバック（データを処理開始前に戻す事）させて異常終了させるか、或いは、例外処理を起動する直前の部位に制御を戻し、▲４▼前記▲２▼で取得した情報を元に人間の判断によって以降の対応を行うことが行われていた。
【０００５】
尚、従来技術による前記エラー発生時の例外処理に関する技術が記載された文献としては、例えば特開平８−３１４７５１号公報や特開２０００−３３９２８９号公報が挙げられ、これら公報には、過去の障害事例をデータベースに保持しておき、該データベースを参照して例外処理に対処する手法が記載されている。
【０００６】
【発明が解決しようとする課題】
前述の従来技術による例外処理の手法は、▲１▼エラーが発生して例外処理に制御を移すときに応用プログラムから例外処理にエラー情報を渡すが、これを渡す為のコード量が膨大なため生産性が悪くなると言う不具合と、▲２▼応用プログラムが例外処理をすすめる過程で、多くのオブジェクトを呼び出し、オブジェクトの中でエラーが発生したかどうかをリターンコードから判断するなど例外処理結果を判断するコードが必要なため、応用プログラムが実際の処理をすすめるコードよりもエラー処理のコードが大部分を占め維持性を悪くすると言う不具合と、▲３▼例外処理ではエラー発生時の直接的な現象を示す情報を表示するのみで、エラーの原因を推定する事はなく、表示された情報を見て人間がエラーの内容を分析するため、業務用システム運用に専門家の知識が必要であると言う不具合があった。
【０００７】
本発明の目的は、前述の従来技術による不具合を除去することであり、エラー要因を推定して表示し、システム運用時に個々の業務システム特有にありがちな障害切り分けが不要なオブジェクト指向言語でのアプリケーション開発におけるエラー処理方法を提供することである。
【０００８】
【課題を解決するための手段】
前記目的を達成するために本発明は、エラー発生によって例外処理が生じ、該例外処理の例外名とエラー詳細コードとを発生するエラー処理方法であって、エラー発生時の例外名と該例外名に対応する障害要因との対応を格納した単一要因データベースと、エラー発生時のエラー詳細コードと該エラー詳細コードに対応する障害要因との対応を格納した詳細コード別障害要因辞書と、エラー発生までの開始メッセージを登録しているが終了メッセージを受けていない全オブジェクトのクラスの状態を格納したクラス別障害可能性データを格納したクラス別機能クラス−障害要因辞書とを設け、前記例外処理が発生した場合、前記エラーによって発生した例外名をキーとして単一要因データベースを検索して障害要因を検索する第１ステップと、該第１ステップにより障害要因が検索できない場合、前記エラーによって発生したエラー詳細コードをキーとして詳細コード別障害要因辞書を検索する第２ステップと、該第２ステップにより検索した障害要因と前記クラス別機能クラス−障害要因辞書に格納した全オブジェクトに含まれるクラスとを比較して障害要因を検出する第３ステップとを実行することによって、エラー要因を推定することを特徴とする。
【０００９】
【発明の実施の形態】
以下、本発明の一実施形態によるオブジェクト指向言語でのアプリケーション開発におけるエラー処理方法を図面を参照して説明する。図１は、本実施形態によるオブジェクト指向言語開発におけるエラー処理方法の全体構成を示す図であり、図２は処理開始時と終了時に状態管理クラスに順々に制御が移って行くさまを記録することを説明するための図、図３はエラーの発生から「業務例外（Ｅｘｃｅｐｔｉｏｎ  ｈａｎｄｌｉｎｇ）クラス」による障害情報の取得乃至障害要因の推定方法を説明するための図である。
【００１０】
図１に示す本発明の一実施形態によるオブジェクト指向言語開発におけるエラー処理方法の全体構成は、オブジェクト指向言語のプログラムが実行できるコンピュータで稼動する複数のコンポーネントの集まりであり、図中、符号１１￣１４は、処理形態の種類毎に作るフレームワークであり、該フレームワークは、生産管理／販売管理／営業事務といった企業等の業務を行う応用プログラムの内、パソコンから入力を行いサーバシステムを使って情報処理する場合の代表的な処理形態を実行するコンポーネントである。
【００１１】
＜フレームワークの説明＞
前記フレームワーク１１〜１４は、端末から入力された内容に応じて端末パソコンに応答を行うまでの一連の処理全体を制御するものであって、例えば更新処理フレームワーク１１は、データベースから必要な情報を読み込んで内容を表示し更新する形態の機能を制御するものであり、検索処理フレームワーク１２は、データベースから情報を読み込んで内容を表示し更新する形態の機能を制御し、帳票発行フレームワーク１３は、データベースから情報を読み込んで帳票を発行し、新規登録フレームワーク１４はデータベースに新規情報を登録するものである。
【００１２】
＜フレームワークの役割とフレーム基本機能＞
前述フレームワーク１１〜１４の役割は、端末パソコンから入力された内容を受取り、応答時の出力メッセージを編集して端末パソコンに送るまでの一連の処理全体を制御することであり、例えば更新処理フレームワーク１１は、ユーザ等の認証１１１／データベース接続１１２／入力チェック１１３／検索−業務ロジックの実行−データ更新を含む業務処理（データベース操作）１１４／出力編集１１５／データベース切断１１６の各基本機能処理を順に実行するものであり、他のフレームワーク１２〜１４においても同様である。
【００１３】
＜業務対応クラス群の説明＞
図中上段の符号２１〜２３は、複数の業務対応クラス２１〜２３から成る業務対応クラス群を示し、更新処理フレームワーク１１で使用される例であり、例えば商品データベースの更新処理、或いは在庫データベースの更新処理と言った単純な物から、受注変更のような在庫データベースや受注データベース等複数のデータベースの更新を担う形態のものがある。本実施形態におけるエラー処理方法は、前述の業務フレームワークに分類される各業務処理毎に本業務対応クラスを作り、これら業務対応クラス２１〜２３は、入力チェック／業務処理／出力編集の３個の決まったメソッドを持ち、更新処理フレームの同名のフレーム基本機能から呼出し、業務処理を行うコードはここに記される。
【００１４】
＜基本機能対応クラス群の説明＞
図中右上の符号３１〜３３は、業務対応クラス以外の機能を示し、一般認証管理クラス３１と、データベース接続クラス３２と、共通部品クラス３３とから成り、フレームワーク基本機能１１〜１４から呼出される。前記一般認証管理クラス３１は、認証管理メソッドを含み、データベース接続クラス３２は、業務データベース接続機能／業務データベース切断機能／例外処理用データベース接続機能／例外処理用データベース切断機能を含み、共用部品クラスは、日付取得メソッド／住所編集メソッド／カレカダーメソッドとを含む。
【００１５】
＜データベースアクセスクラス群の説明＞
図中右側の符号４１及び４２は、ＡＡテーブルアクセスクラス４１及びＢＢテーブルアクセスクラスのデータベースアクセス機能のクラスであり、テーブル毎に１個作られるものである。これらデータベースアクセスクラスは、各々当該テーブルの読出し（ｓｅｌｅｃｔ）／挿入（ｉｎｓｅｒｔ）／更新（ｕｐｄａｔｅ）等の必要なアクセス機能をメソッドとして実装している。
【００１６】
＜状態管理クラスの説明＞
図中左端に示す符号５１は、状態管理クラスを示し、この状態管理クラス５１は、前記フレームワーク１１〜１４、フレーム基本機能１１１〜１１６、クラス２１〜２３、４１〜４２の処理開始時と終了時に状態管理クラスにメッセージを送りフレームワーク開始に始まり、順々に制御が移って行くさまを記録するものであって、詳細は図２を参照して説明する。
【００１７】
＜業務例外（Ｅｘｃｅｐｔｉｏｎ）クラスの説明＞
図中の符号６１は、業務例外クラスを示し、この業務例外クラス６１は、フレームワーク１１〜１４、フレーム基本機能１１１〜１１６、各クラス２１〜２３、４１〜４２の処理中にエラーが発生し対応する処理が必要なときに処理要求を行い実行させるクラスであって、本実施形態の中心をなすものである。
【００１８】
＜更新処理の説明＞
次に図１を参照しながら、更新処理を行なう場合を説明する。まず企業等の業務を行う応用プログラムが、更新処理フレームワーク１１を使って更新処理の動作を開始し、該フレームワーク１１に含まれる認証他の機能１１１〜１１６を逐次実行する。詳細に説明すると当該認証１１１は、前記一般認証管理クラス３１を呼び出してユーザ認証を行い、データベース接続１１２によりデータベースシステムと接続した後、入力チェック１１３によって更新処理用クラス２１〜２３のいずれか一つの入力チェックメソッドを使って入力チェックを行う。
【００１９】
次いで本システムは、業務処理（データベース操作）１１４を前記入力チェック１１３の時と同じ更新処理用クラス２１〜２３の業務処理メソッドを使って行い、これらすべての処理の実行開始と終了時に、本システムは、状態管理クラス５１にメッセージを送って状態を記録し、これら一連の処理過程においてエラーが発生したときに前記業務例外クラス６１を呼出し、エラー処理を行う。
【００２０】
特に本実施形態においては、当該業務例外クラス６１を呼出し、従来のように引数、或いは共用メモリ領域を使ってエラー情報を渡すことはない。この業務例外クラス６１は、エラーの詳細コードを自クラスで取得し、次に状態管理クラス５１からオブジェクトの状態を取得し、詳細コードとオブジェクトの状態を元に後述の障害詳細−要因辞書２４０を参照し障害要因を推定する。この業務例外６１の詳細な説明は図３を使って後述する。
【００２１】
＜状態管理クラスによるオブジェクト状態の収集の収集＞
次に図２を参照して状態管理クラスにおけるオブジェクトの状態収集方法を説明する。図２は、更新処理のフレームワーク３２１を例にして、該フレームワークと、該フレームワーク内の基本機能が必要なクラスを呼出して業務処理を実行する事と、各オブジェクトから状態管理クラスに開始・終了メッセージを送り、処理の進行状況を状態管理クラスで把握する方法を表している。
【００２２】
本例の場合、状態管理クラス３１１は、更新処理の形態に基き、必要なフレーム基本機能３１や業務処理機能（データベースアクセスクラス）４１をオブジェクトとして呼出し、更新処理全体を制御する。状態管理クラス３１１は、フレームワークの中の同名の機能を実行するときに、当該クラスの内、適当なオブジェクト、例えばアクセス部品データベースのクラスとして呼出される。本実施形態においては、１個のクラスがデータベースの１個のテーブルに対応しており、読込み／更新／挿入／削除の機能を持ち、業務処理機能からオブジェクトとして呼出される。
【００２３】
前記状態管理クラス３１１は、応用プログラム内すべてのオブジェクトの開始と終了の度にメッセージを受け取り自クラス内のメモリに展開したテーブル３１２で状態を把握する機能を持つ。この状態管理クラスの管理内容テーブル３１２は、管理項目と更新処理の途中までの内容を例として示す機能を持ち、更新処理フレーム２１からのフレーム全体の開始メッセージの記録である通番１と、更新処理フレーム２１が認証機能を実行するときの開始メッセージの記録である通番２と、フレーム基本機能クラス群の一般・認証クラス３１に制御が移った時の開始メッセージの記録である通番３と、当該一般認証クラス３１の処理完了時の終了メッセージの記録である通番４と、更新処理フレーム３２１が認証機能を完了するときの終了メッセージの記録である通番５と、更新処理フレーム３２１がデータベース接続機能を実行するときの開始メッセージの記録である通番６と、フレーム基本機能クラスのデータベース接続クラス３２に制御が移った時の開始メッセージの記録である通番７と、当該データベース接続クラス３２の処理完了時の終了メッセージの記録である通番８と、更新処理フレーム３２１がデータベース接続機能を完了するときの終了メッセージの記録である通番９と、更新処理フレーム３２１が入力チェック機能を実行するときの開始メッセージの記録である通番１０と、ユーザ業務処理機能クラス群４１の所要の更新処理クラスに制御が移った時の開始メッセージの記録である通番１１とで表す各項目を持ち、これら項目に前述の各データを登録する。この様に本実施形態による状態管理クラス３１１は、管理内容テーブル３１２を用いてフレームワークの開始からの実行履歴と、ある時点での実行中のオブジェクトを捉える機能を持つ。
【００２４】
＜エラーの発生から、業務例外クラスによる障害情報の取得と、障害要因の推定方法の説明＞
図３は、エラーの発生から、業務例外クラスによる障害情報の取得と、障害要因の推定方法を説明するための図であり、図中の更新処理フケームワーク１１は、応用プログラムによる業務処理全体を示し、内容として前図で説明したフレームワーク１１１、業務処理クラス群１１２、フレーム基本機能クラス群１１３、データベースアクセス部品クラス群１１４を含み、符号１１５ａはエラーが発生した事を示しており、エラー発生以降の流れは後述する。
【００２５】
状態管理クラス１２０は、前述の様に業務処理におけるメソッドの呼出し情報／オブジェクトの状態等、応用プログラムの進行状況を管理内部テーブル３１２によってで把握しているものとする。また業務例外クラス２１０は、前記エラー発生１１５ａにより呼び出され、例外（Ｅｘｃｅｐｔｉｏｎ）名の取得２１１／例外（Ｅｘｃｅｐｔｉｏｎ）の詳細情報と付加情報の取得２１２／単一要因データベース２５０を検索し、詳細情報だけによるエラー要因特定の試行２１３／エラー発生までの関連する全オブジェクトの状態の取得２１４／詳細情報からの障害要因の取得２１５／障害要因と機能クラスの相関チェック２１６／メッセージの編集・表示２１７までの機能を順次実行し、障害情報の取得と状態管理クラスで収集した情報と合せて障害要因の推定を行なうものである。
【００２６】
ここでエラーが発生する基本的原因は、大別して、プログラムが呼出したＡＰＩ等にエラーが発生し例外を引き起こしたケースＡ、或いは応用プログラム自身でエラーを発生させるケースＢが考えられる。前記ケースＡの場合は、呼出すＡＰＩや関数によってエラー発生時の例外が異なり、例として、Ｊａｖａ（登録商標）言語でデータベースに関するエラーが発生した場合「ＳＱＬ  Ｅｘｃｅｐｔｉｏｎ」という名のデータベースに関する例外が発生する。前記例外名の取得２１１は、この発生したエラーが受け取った例外からデータベース関連の例外であることを「ＳＱＬ  Ｅｘｃｅｐｔｉｏｎ」により特定する。
【００２７】
前記例外の詳細情報と付加情報の取得２１２は、上記例の「ＳＱＬ  Ｅｘｃｅｐｔｉｏｎ」の場合ではＳＱＬコードが詳細情報として付随する特性があるため、この例外に付随した付帯情報も取得する。
【００２８】
前記試行２１３は、詳細情報が決まれば障害要因を特定できる場合のエラーかどうかを判定するものであって、本実施形態においては、例外（Ｅｘｃｅｐｔｉｏｎ）名と詳細コードに対応した障害要因との関係を格納したテーブル２５０ａを含む単一要因辞書２４０を使用して障害要因を特定する。この試行２１３は例外名と詳細情報を与えて、それだけで障害要因を特定できる場合障害要因を返すクラスであり、ここで障害要因が特定できたときは、メッセージを編集・表示２１７に制御を移し、特定できないときは全オブジェクト状態の取得２１４を行なう。
【００２９】
このエラー発生までの関連する全オブジェクトの状態の取得２１４は、エラー発生時に生存する全オブジェクトの情報を状態管理クラス１２０から取得するものであって、生存する全オブジェクトとは、状態管理クラス１２０の監視下において開始メッセージを登録しているが終了メッセージを受けていないクラスを言う。
【００３０】
前記障害要因の取得２１５は、エラーの詳細情報、例えばエー発生時の詳細コードと、該詳細コードに対応した障害要因を格納した障害要因テーブル２４０ａを含む詳細コード別障害要因辞書２４０を元に障害要因を取得する。この詳細コード別障害要因辞書２４０は、応用プログラムの動作中に発生しうるエラー詳細情報（例外名／エラー詳細コード／エラーメッセージ内容／障害要因）を網羅し、それらの発生要因をエラーの種別という形で格納し、エラーの詳細情報（詳細コード）を与えることにより障害要因を得る辞書であり、この障害要因の取得２１５によって同じ詳細コードが見つからない場合は要因不明として表示する。尚、この障害要因の取得２１５は、例えばエラー発生時のメッセード内容をキーとして障害要因を検索する様に構成しても良い。
【００３１】
前記障害要因と機能クラスの相関チェック２１６は、機能クラスと障害要因との対応を示すテーブル２３０ａを含む機能クラス−障害要因辞書２３０を用い、前述の生存するオブジェクトとエラーの発生したオブジェクトを元に、発生し得る障害要因を取得するものである。
【００３２】
前記障害要因の取得２１３及び２１５は、取得した詳細情報からの障害要因と比較し一致した物を推定要因とするものであるため、障害要因が複数見出される場合があり、その場合はすべてを「推定要因」とし、次いでメッセージを編集・表示２１７において、これまでの情報を元にメッセージを表示する。この表示する項目は、例外名から得たエラーの種類、生存するオブジェクトの情報から得た発生部位、エラー詳細情報、例外に付帯してきた情報、推定要因である。
【００３３】
この様に本実施形態によるオブジェクト指向言語でのアプリケーション開発におけるエラー処理方法は、エラー発生時の例外名と該例外名に対応する障害要因との対応を示す単一要因データベースと、エラー発生時のエラー詳細コードと該エラー詳細コードに対応する障害要因との対応を示す詳細コード別障害要因辞書と、エラー発生までの状態管理クラスの監視下において開始メッセージを登録しているが終了メッセージを受けていない全オブジェクトのクラスの状態を格納したクラス別障害可能性データを格納したクラス別機能クラス−障害要因辞書とを設け、例外処理が発生した場合、前記エラーによって発生した例外名をキーとして単一要因データベースを検索して障害要因を検索する第１ステップと、該第１ステップにより障害要因が検索できない場合、前記エラーによって発生したエラー詳細コードをキーとして詳細コード別障害要因辞書を検索する第２ステップと、該第２ステップにより検索した障害要因と前記クラス別機能クラス−障害要因辞書に格納した全オブジェクトに含まれるクラスとを比較して障害要因を検出する第３ステップとを実行することによって、エラー要因を推定することができ、システム運用時に個々の業務システム特有にありがちな障害切り分けを不要とすることができる。
【発明の効果】
以上述べた如く本発明によれば、、エラー発生までの関連し且つ状態管理クラスにおいて開始メッセージを登録しているが終了メッセージを受けていない全オブジェクトのクラスの状態を監視し、エラーによって発生したエラー詳細コードをキーとして詳細コード別障害要因辞書を検索して得た障害要因と比較することによって、エラー要因を推定することができる。従って本発明によれば、業務用コンピュータシステム開発の生産性と、維持性（保守性）を向上させる事ができ、更にエラー要因を推定して表示するためシステム運用時に個々の業務システム特有にありがちな障害切り分けが不要で  運用コストの低減を図ることができる。
【図面の簡単な説明】
【図１】本発明の一実施例によるオブジェクト指向言語開発におけるエラー処理方法の全体構成を示す図。
【図２】本実施形態による処理開始時と終了時に状態管理クラスに順々に制御が移って行くさまを記録することを説明するための図。
【図３】本実施形態によるエラーの発生から「業務例外（Ｅｘｃｅｐｔｉｏｎ）クラス」による障害情報の取得乃至障害要因の推定方法を説明するための図である。
【符号の説明】
１１：ワークフレーム、１２０：状態管理クラス、２３０：機能クラス−障害要因辞書、２４０：障害詳細−要因辞書、２５０：単一要因データベース、２１０：業務例外処理。
【図１】
2004287700.tif 000003
【図２】
2004287700.tif 000004
【図３】
2004287700.tif 000005