システム方式設計書（アプリケーション方式設計書）にはどんなことを書いたらいいのでしょうか。
今回はエラー処理方式についてです。
時間と労力をかけて設計するシステム方式設計です。
役に立つ設計書にしましょう。
エラー処理方式に書くこと
エラー処理方式で書くべきことは大きく2つです。
・このシステムではどんなエラーが起きるのか
・起きたエラーの処理方法
まずは、このシステムが動作する中でどのようなエラーが起きるのかを整理します。
大きくはアプリケーションエラーとシステムエラーに分けられます。
アプリケーションエラーというのは利用者の操作や入力内容によって起こることを想定しているエラーです。
例えば、入力項目の必須チェックや、業務固有の要件で値の適正範囲などをチェックしたときに起こすエラーです。
一方、システムエラーは通常操作では発生しないようなエラーでシステムのトラブルを意味します。
どのようなエラーを扱うのかを整理します。
ここで整理したエラーをどのように処理するのか仕組みを設計します。
エラー処理方式の「概要」に書くこと
概要では基本的にはオーナーからの要件を整理します。
エラーをどのように画面に表示ししたいとか、システム管理者にどのように通知したいとか。
画面の入力チェックを行う場合は、どんなチェックを行いたいのかを整理します。
エラー処理方式の「方式設計」に書くこと
まずは、どのようなエラーが起きるのかを整理ます。
大きくは業務エラーとシステムエラーに分かれます。
例えば次のようなイメージです。
アプリケーションエラーについては、構築するシステムで自己チェックをして意図的に発生させるエラーです。
どの順番でチェックをするのかも決める必要があります。
発生するエラーが決まったらエラーを処理する仕組みを設計します。
アプリケーションエラーの場合は、チェックをする仕組みで行うのか設計します。
共通備品化も検討します。
また、エラーを画面に表示するための仕組みやエラーの出し方についても設計します。
この点についてはオンライン処理方式やバッチ処理方式の中で設計済みなら不要です。
システムエラーについては予期しないエラーとなります。
OSのトラブルであってり、ミドルウェアのトラブル、想定しないデータが流れてきた場合に例外処理をして発生します。
Javaなどの場合、Exceptionという形で発生します。
このExceptionをキャッチしてシステム管理者に通知したりログに出力するための仕組みを設計しておく必要があります。
エラー処理方式の「実装方式」に書くこと
エラー処理方式の「実装方式」に書くことはあまりありません。
アプリケーションエラーのチェック処理を共通部品化した場合は、その部品の利用方法を説明します。
システムエラーの処理はアプリ基盤の中に組み込むことが一般的です。
開発者が個別に処理を書くことは少ないです。
ただし、例外（Exception）の取り回し方などのルールは提示しておく必要があります。
業務処理クラスで発生したExceptionはすべて上位クラスにthrowするなどのルールです。
コメント