シリーズastah*で業務をまとめ、プログラムまでのトレーサビリティを取るのつづきです。
エンタープライズ系の開発をトレーサビリティをとって行う流れをまとめるとこんなかんじ。
・ユースケース図
↓
・アクティビティ図
↓
・（ユースケースシナリオ＝astah＊にない）
↓
・アクティビティの構成を示したクラス図
↓ ↓正規化
画面定義、帳票定義 ＥＲ図
ユースケース→ユースケースシナリオまでは、要求仕様の話で、それ以降が設計の話。
要求仕様までのところは終わっていて、前回、要求仕様から設計にどう落とすのか？という
話を書きました。
結局まとめると、こういうこと・・・
ユースケースシナリオ（＝要求仕様書）に、
・どんなメディア（画面、帳票）にアクセスするかというバウンダリが明記されていれば、
設計者としては、メディアごとのフレームワーク（例：画面はＳｔｒｕｔｓとか）を決定すると
・どんな設計になるかが、きまってしまう。
今回は、この状態を、具体的に、クラス図で表現することとします。
■まず、要求仕様
航空券発券の話で、「空席確認」のユースケースシナリオについて考えます。
■今回作成するもの
ユースケースごとのクラス構造を、ユースケースシナリオから作ります。
＜＜前提条件＞＞
ユースケースシナリオには、上記に示したように、どんなメディア（画面、帳票）にアクセスするかというバウンダリが明記されているものとします。
メディアごとのフレームワーク（例：画面はＳｔｒｕｔｓとか）を決定しているものとします。
■フレームワークをきめます。
全体像：ＭＶＣにします。
・１ユースケースに対して１つのＢｅａｎがあり、そこから、データアクセスしたり、画面アクセスしたりします。
画面：
・Ｓｔｒｕｔｓを採用します。
・１画面につき、１アクションとし、各アクションは、ユースケース対応beanを呼び出します
→ユースケース対象beanはセッションに入っている。入っていなければnewしてつくる。
・呼出し後、ユースケース対応beanにデータを設定し、いろいろ処理をします。
・結果はユースケース対象Ｂｅａｎに保持され、呼び出し元に返ります
・次画面は、ユースケース対象Ｂｅａｎのデータ内容をみて、表示を行ったりします。
ＤＢアクセス
・オブジェクト（ＤＡＯ）を使って、データをアクセスします。
・このＤＡＯは１トランザクションであり、複数のテーブルを操作することもありえるとします。
・テーブル構造、テーブルとＤＡＯとのアクセスは、ＤＡＯ内部のことであり（隠蔽化されている）
外には見えないので、ＤＡＯまでを、構造として書きます。
帳票（今回はない）
・オブジェクト（Sheet）を使って、帳票を作成します
・このＳｈｅｅｔは、帳票の種類ごとにあります。
・帳票出力の仕方は、Ｓｈｅｅｔ内部のことであり（隠蔽化されている）
外には見えないので、Ｓｈｅｅｔまでを、構造として書きます。
こんなかんじ
■上記のフレームワークをユースケースシナリオに当てはめると・・・
全体＝ユースケース１つにつき１こ
・空席確認Bean（KuKakuninBean)
画面＝「画面」と出てくるところ
・空席確認画面
KuKakunin_jsp 表示画面
KuKakuninAction アクション画面
KuKakuninActionForm データ
・空席結果画面
KuKekka_jsp 表示画面
KuKekkaAction アクション画面
KuKekkaActionForm データ
データ（ＤＢアクセス）
・空席確認（KukakuninDAO）
っていうことになります。
■クラス図にすると
こんなかんじ
関連の線が、この場合、引かれるのかどうかはびみょーだけど、
みやすくするために引いてみました。
また、色は、それぞれの部分を見やすくするためにつけてみました
クラス内のアトリビュートやメソッドは、この時点で埋まるものもあるけど（Actionには、execute()があるはず）
今回は、ま、いいです。
ってことで、今回は、ここまで。
次回は画面定義。
