![[PukiWiki]](image/seasar.png "[PukiWiki]")
新業務分析が完了しているところから開始し、
外部設計、内部設計までが対象スコープです。
バウンダリで発生するイベント(画面表示時、ボタンクリック等)から
呼び出されるコントロールは一つだけです。
もっと実装寄りにすると、
StrutsのActionクラスのメソッドから呼び出されるコントロールは一つ
のように読み替えることが出来ます。
コントロールには状態を持ちません。
コントロールが状態を持たないので、
コントロールを構成するユーザ機能も状態を持ちません。
バウンダリに一時的なセッションの状態を持ち、
エンティティ(リソース)に永続的な状態を持つだけです。
コントロールから別のコントロールを呼び出してはいけません。
コントロールが汎用的な名前であったとしても、コントロールは汎用的ではありません。
そのコントロールは、同じ名前の汎用的なユーザ機能を呼び出しているだけで、
バウンダリ依存なものであることに変わりありません。
まずインターフェイスありきのため、宣言的例外は基本的に使えません。
また使う必要もありません。
但し、どのような例外が発生するか位は、実装クラスのJavadocに書いておきましょう。
例外のcatchは業務ロジックで行い、ログ出力やロールバックすることになります。
大抵はそのまま投げて、バウンダリに伝播させ、画面上のエラーメッセージに変換したりします。
ユーザ機能はその内容から自動的にインターフェイスに分類できます。
まず、その種類を考えます。
次に個別のインターフェイスの識別として、
ということになります。
ここまでルール化されているので、
ユーザ機能抽出と同時にインターフェイスの抽出が出来るようになります。
くーすにクラス図は要りません。
クラス図は、クラス間の静的構造の情報を記述するものですが、
少なくとも、業務ロジック、補助ロジックについては、
シーケンス図で表す以上の静的構造は存在しません。
あるとすれば、
ぐらいです。
これらについては、必要であれば作って下さい。
プロセスフローを参照して下さい。
新業務フローを入力として、
を平行して実施。
ロバストネス図が出来たら
を平行して実施します。
これだけです。
後は、これらの成果物を使って実装・テストを行うだけです。
これは、くーすの成果物ではなく、要求する入力になります。
バウンダリのフローとして記述されます。
業務フローを参照して下さい。
UIのモックです。
HTMLなり、VBなり、作るシステムによって変わってきます。
を纏めた図です。
ロバストネス図を参照して下さい。
UIの実装に必要な情報を纏めたものです。
UI仕様書(xls)を参照して下さい。
エンティティの仕様書です。
オブジェクトとしての性質に加えて、テーブルの物理設計についての情報も含めます。
エンティティ仕様書(xls)を参照して下さい。
UMLのシーケンス図で表したホワイトボックスシナリオです。
シナリオ毎に作られます。
シナリオシーケンス_ログイン
シナリオシーケンス_コメント一覧表示
シナリオシーケンス_コメントを登録する
を参照して下さい。
インターフェイスの仕様書です。
メソッド毎に事前条件、事後条件を記述します。
実装クラスについての仕様書は作りません。
実装クラスの仕様書が必要だと感じた場合は、
シナリオシーケンスで抽出されていないユーザ機能があるかもしれません。
コンポーネント仕様書(xls)を参照して下さい。
は、やった方が良いです。
他にも、内部設計完了後の顧客レビューをやることもあるかもしれません。
もちろん、それぞれ内部レビューはやっておくべきです。
