![[PukiWiki]](image/seasar.png "[PukiWiki]")
宣言的例外のメリットは、発生する例外を明示的に定義することです。
デメリットは、処理しない場合に使用する側のシグネチャを汚染してしまうことです。
これは、IDDとしては許容できないものです。
しかし、例外的に使えるケースがあります。
業務ロジックでRuntimeExceptionを投げられない、又は、投げたくない場合です。
具体的には、EJBを使ってたり、EJBの代替実装にする場合などです。
こういう場合は、業務ロジックでRuntime系の例外を処理、又は、ラップして、宣言的例外で投げることになります。
基本的にコントロールをトランザクション境界とします。
特殊な要件が無い限りはこれでよいはずです。
処理失敗時に自動再実行する場合、
コントロールのトランザクションの外側で再度呼び出します。
アスペクトでやるのが良いでしょう。
一時的な状態(=セッション情報)は、画面からの入力を除けば、
コントロールの戻りとして取得することになります。
それを保持するかどうかなどは、
まず、ロバストネス図の補足として記述する。
その後、UI仕様書に記述する。
ということになると思います。
俯瞰的なチェックがロバストネス図では難しい場合は、別途適切な表を作りましょう。
共通メニューのようなバウンダリが想定できるのであれば、それを。
出来ないのであれば、ログアウトリンクのようなバウンダリを設定し、ロバストネス分析を行います。
その上で、どの画面に含まれるかという情報をバウンダリの補足として記述します。
UI仕様書の作りとしても同様にした方が作業が楽になります。
