（※前回からの続きです。）
■ 「Condition」の定義
五つの終了ケース類型を改めて下にまとめます。それぞれにイメージカラーを付けています。（※さながらトリアージュの優先度分類風。）筆者はこのカラー表現を「Condition」と称することとしています。
Condition 終了ケース 品質保証・
管理における
「故障
（failure）」
か？
GREEN 成功終了／
肯定的正常終了
completed - No（正常） positive regular YELLOW 失敗終了／
否定的正常終了
〔機能要件〕
incomplete recoverable No（正常） negative irregular ORANGE 失敗終了／
否定的正常終了
〔非機能要件〕
incomplete recoverable No（正常） negative irregular RED 異常終了〔外的要因〕 incomplete unrecoverable Yes（異常） - - BLACK 異常終了〔内的要因〕 incomplete unrecoverable Yes（異常） - -
■ 呼び出した側における、各終了ケースのハンドリング指針
「終了ケースのハンドリング」とは、呼び出した処理が特定の終了ケースだったとき、処理の呼び出し側が、「呼び出し側のロジックを呼び出しているさらに上位のロジック階層へはどのような終了ケースとしてリターンするか」、という課題です。
実のところ終了ケースの類型化の目的は、処理を呼び出した側において、処理の終了をキャッチした後それをどのようにハンドルできるかについて対応をパターン化しようというところにありました。
以下に終了ケース毎のハンドリング指針を示します。
- GREEN：成功終了
・そのままアプリケーションの実行を継続できます。
- YELLOW：失敗終了〔機能要件〕
・内容によって、呼び出した側のロジック自身について、成功終了とするか、失敗終了とするか、異常終了とするか、個別の判断ロジックを実装する必要があります。
（例１）商品を取り扱い停止状態に変更しようと当該サービス（＝処理）を呼び出したら、「既に取り扱い停止状態である」という失敗終了となった。この事象は、データの最新状態反映のラグに起因するといえ、かつ事後状態として問題がない。よって処理呼び出し側としては、このケースは成功終了として扱うこととする。（例２）処理呼び出し側のロジックＡにてパラメータＸに基づいて商品参照を呼び出したら、「Xなる商品は存在しない」という失敗終了となった。パラメータＸは、処理呼び出し側の同一プログラム内でロジックＡの直前に実行されるロジックＢが準備していて、設計上この事象は発生し得ないはずである。このケースは内的要因による異常終了として扱うこととする。（例３）ユーザーエージェントから引き渡されたパラメータYに基づいて商品参照処理を呼び出したら、「Yなる商品は存在しない」という失敗終了となった。このケースでは、当該失敗終了を上位層たるユーザーエージェントにそのまま伝播させることとする。
- ORANGE：失敗終了〔非機能要件〕
・処理呼び出し側にて、この終了ケースをさらに上位層にそのまま転送あるいは伝播させればよいです。・最上位層（＝ユーザーエージェント）では、その内容に応じた適切なガイドをユーザーへ表示します。（※ガイドの内容は個別的となりますが、ガイドの表示処理の方式は一般化、共通化できるでしょう。）
- RED：異常終了〔外的要因〕
・処理呼び出し側にて、この終了ケースをさらに上位層にそのまま転送あるいは伝播させればよいです。・最上位層（＝ユーザーエージェント）では、「システムが故障状態に陥った＝システムに障害が発生した」旨を表示するのみです。
- BLACK：異常終了〔内的要因〕
・処理呼び出し側にて、この終了ケースをさらに上位層にそのまま転送あるいは伝播させればよいです。
・最上位層（＝ユーザーエージェント）では、「システムが故障状態に陥った＝システムに障害が発生した」旨を表示するのみです。
まとめます。
・失敗終了〔非機能要件〕、異常終了〔内的・外的要因〕に対応するハンドリングは、ユースケース横断的な共通の機構として実装可能と言えます。
・対して失敗終了〔機能要件〕は、各ユースケース（の代替フロー）に対応した個別の判断ロジックを記述する必要があります。
