エラーハンドリング

Q社は，業務システムの受託開発会社である。Q社は，スーパーマーケットの複数の店舗を運営するB社から，CRM（Customer Relationship Management）システムの開発と運用保守業務を受託した。CRMシステムは各店舗で利用され，顧客からの意見やクレーム，店舗での対応の内容が登録・蓄積される。CRMシステムを運用する際の関係者の一覧を表1に示す。

Q社は，システムのリリース後に想定される，店舗からの問合せに対する迅速な対応を可能にするために，想定される問合せのパターンと対応方法を事前に整理し，対応の際に必要な要件をシステムの設計に反映させることにした。

〔CRMシステムの構造〕

CRMシステムのクラス図（一部）を図1に示す。AbstractController, AbstractService及びAbstractDaoは，それぞれ画面遷移，ビジネスロジック及びデータベースアクセスの共通処理が実装された抽象クラスである。これらのクラスをaしたクラスを作成して，具体的な機能を実装する。ログを出力するにはLoggerクラスを利用する。ログの出力時には“DEBUG”，“ERROR”などの，ログの種別（以下，ログ種別という）が記録される。図1に示すクラスを使った処理の流れの例として，システムにログインする際のシーケンス図を，図2に示す。

クリックで拡大

図1　CRMシステムのクラス図（一部）

この図の中に空欄 b があります

クリックで拡大

図2　システムにログインする際のシーケンス図

この図の中に空欄 b・c があります

利用者がログイン画面で認証に必要な情報を入力しログインを実行すると，LoginControllerのログイン実行メソッドが呼び出される。ログイン実行メソッドは，画面から入力された情報をAuthServiceに引き渡す。AuthServiceは，UserDaoに実装されている，利用者情報の検索を行う機能を用いて，認証の判定に必要な利用者情報をデータベースから取得する。AuthServiceは，取得した利用者情報を用いてログイン認証の判定を行い，結果を返す。

プログラムの実行中にエラーが発生した際の，例外処理用のクラスとしてExceptionクラスがある。Exceptionクラスは，エラーの詳細情報として，エラーの発生箇所のソースファイル名，行番号，メソッドの呼出し履歴及び直接的な原因を示すメッセージ文字列をもつ。エラー発生時には，エラーの発生箇所でExceptionクラスのオブジェクトを作成し，呼出し元ではそれを使って例外処理を行う。

〔CRMシステムのエラーの種別の整理とその対応〕

Q社は，運用中に起き得るエラーの種別（以下，エラー種別という）を整理し，対応方法について検討した。エラー種別と運用担当者の対応を表2に，対応を行うために必要な出力機能及び出力内容と，出力内容を参照する関係者を表3に示す。

表2，表3についてレビューを行ったところ，次の3点が指摘された。

指摘事項の(1)に対応するために，^①監視の機能を用意することにした。監視の機能は，監視対象の情報を定期的に取得し，エラー発生時の特徴を検出した場合に電子メールで運用担当者に通知する。指摘事項の(2)については，表3の^②出力内容を一部変更することにした。指摘事項の(3)については，アスペクト指向プログラミングを導入して，プログラムの処理の中で，要所ごとにログを出力することにした。

〔アスペクト指向プログラミングの導入〕

レビューの指摘事項の(3)に関連して，利用者が行った操作内容を一律でログに出力することにし，これを実現するためにアスペクト指向プログラミングを導入することにした。

アスペクト指向プログラミングでは，特定のルールを定義しておくことによって，そのルールに合致する全ての箇所で同じ処理を実行させる。ルールの定義の条件にはクラス名，メソッド名に含まれる文字列のパターンが利用できる。また，特定の条件に合致する場合には実行の対象から除外するように指定することもできる。

ここでは，実装上の制約ができるだけ少なくなるようなルールの定義方法で，画面遷移に関するクラスに実装された全てのメソッドについて，クラス名，メソッド名及び全ての引数の内容をログに出力することにした。これを実現するために，eを親クラスにもつクラスのfには必ず特定の文字列のパターンを含み，それ以外のクラスのfには特定の文字列のパターンを含まないように命名規則を定義した。ただし，秘匿情報や個人情報の保護の観点から，認証に関する情報や，^③顧客情報を扱う箇所はログに出力しないようにした。

Q社は，表2，表3に関する検討結果をシステムの設計に反映させ，開発を開始した。