「astah*を使って、開発の要求仕様から、プログラム作成までを、トレーサビリティを保って、どのように開発するかを書いてみる」という、このシリーズ、以下の手順で説明する予定で、
（１）作るべきもののユースケースを書く
（２）ユースケースシナリオを書く
（３）ロバストネス分析
（４）バウンダリ（画面）、エンティティ（テーブル等）の属性を埋めていく
（５）バウンダリの項目を元に、画面構成を考える。
（６）(必要があれば）エンティティを正規化して、ER図にする
（７）フレームワークを決定する
（８）画面クラスをソースコードに書き直す
（９）エンティティをDBのテーブルと、DAOに書き直す
（１０）コントローラーを書き直す
前回、（９）書いて、のこり１個「（１０）コントローラーを書き直す」なので、
今回、これを書いて、このシリーズをおわりにしてしまいましょう。
■概要と位置づけ
（８）により、画面部分を書きました。
（９）により、エンティティ部分を書きました。
画面はViewであり、このViewは、さかのぼるとユースケースと結びついています。
でも、あるユースケースにおいて、利用するエンティティはさまざまです。
また、違うユースケース間で、同じエンティティを使う場合もあります。
つまり、ユースケースとエンティティ間には、ミスマッチがあります。
これを解決するのがコントローラーで、
コントローラーは、View（＝エンティティ）のデータを受け取って、エンティティやビジネスモデルを操作して、
その結果を受け取って、ビューに値を返します。
■結局
Viewとエンティティ、ないしはビジネスモデルを呼び出す部分をコーディングすることになります。
Strutsだと、Action部分を作ることです。
ただ、Actionの実装において、ビジネスモデルをどこまでアクションに入れるか、入れないか？
の問題があります。Actionは、値の引き渡しだけで、ロジックはすべて、ビジネスモデルにいれてしまうか、
いや、多少の計算は、Actionでやってもよくね？と考えるか・・・
このへんは、現場の偉い人の考え方になってきます。
ってことで、一通り開発の流れを書きました。
このシリーズ、これにて、おしまい。
アクセス
トータル
ランキング
