ダイコン時代の設計手法 - ユースケース分析
ユースケースの管理単位は、画面系なら関連のある複数の画面の組み合わせ、
帳票系なら1帳票、バッチ系ならジョブネット。
ユースケース単位に、ロバストネス分析を行って全体構造を把握します。
ロバストネス分析を行うときにもっと重要なのがコントロール。
コントロールはVO(〜を〜する)で記述します。
画面系の場合は、ほぼリンクやボタンのクリックのイベントが
1つのコントロールになります。
バウンダリでは画面の入出力項目、帳票の出力項目を定義します。
ユースケースでは具体的な画面は意識しない方がいいなんてことが
いわれたりしますが、それはきれいごと。
実際はこの段階でモックを作ったほうがユーザから多くのフィードバックを
引き出すことができ、仕様をつめることができます。
業務ロジックを含まない画面の仕様はここで固めます。
エンティティはER分析のインプットです。
コントロールはステートレス。
状態がある場合は、一時的な状態はバウンダリに、永続的な状態は
エンティティにマッピングします。
この辺は、UI層のモデルの話が絡んできます。
UI層のモデルは画面項目定義に反映され、エンティティはエンティティ定義に
反映されます。
エンティティ定義は、S2DaoではExcelで定義されデータベースとの
ラウンドトリップも実現する予定です。
コントロールはこの後、UI層のコントローラ、サービス層、永続化層に
マッピングします。
UI層のコントローラの仕様は、画面のイベント定義に反映されます。
サービス層の仕様は、サービス定義書に反映されます。
ユースケース記述(ルール記述)を使ってもいいのかもしれません。
- > id:akonさん
ルール記述書は、事前条件・事後条件・シナリオで構成されているもので、
詳しくはまた後で。
永続化層の仕様はSQL定義書に反映されます。
SQL定義書は、S2Daoの定義そのものであってもいいかもしれません。
