「astah*を使って、開発の要求仕様から、プログラム作成までを、トレーサビリティを保って、どのように開発するかを書いてみる」という、このシリーズ、以下の手順で説明する予定ですが、
（１）作るべきもののユースケースを書く
（２）ユースケースシナリオを書く
（３）ロバストネス分析
（４）バウンダリ（画面）、エンティティ（テーブル等）の属性を埋めていく
（５）バウンダリの項目を元に、画面構成を考える。
（６）(必要があれば）エンティティを正規化して、ER図にする
（７）フレームワークを決定する
（８）画面クラスをソースコードに書き直す
（９）エンティティをDBのテーブルと、DAOに書き直す
（１０）コントローラーを書き直す
前回、（５）をやったので、今回は、「（７）フレームワークを決定する」について。
■概要と位置づけ
（５）によって、画面項目と画面遷移、（６）によって、データベース側の項目は決まりました。
つまり、論理的には、もう決まったので、ここからは、どのように、実装をしていくかを考えます。
最近の開発の場合、フレームワークを使って開発するのが主流です。
フレームワークが決まってしまうと、なにを開発すればよいかの大枠がきまります。
なので、実装の最初は、まず、フレームワークに何を選ぶかを決めます。
フレームワークが決定してしまうと、コンポーネント構成なども大体きまってしまいます。
そして、システムの画面と、DBまでのつながりが大まかにきまるので、外部設計的にはひと段落と成ります。
つまり、フレームワークが決定したら、外部設計をまとめて、お客さんに確認をとることで、外部設計的にはひと段落します（フレームワークが決まらないと、外部レイアウトが正しく決まりません。なので、この前で同意を取るのは、危険だったりします）。
■決め方の観点
まず、何を決めるかですが、最近は、MVCで考えることが多いと思います。
V＝ビュー：画面、ユーザーインターフェース
C＝コントロール：画面とモデルのつなぎ
M=モデル：処理部分。
モデルのロジック部分と、データベースアクセス部分がある。
ってことで、
・ビュー→コントロール
ビュー自体は、HTMLファイルとか、JSPファイルとかになり、
コントロール部分は、Javaのソースコードになる。
これをつなぐところにフレームワークが「入ることが多い」
（自動生成してしまうフレームワークとかもあるし、
画面をフレームワーク化とかも、ないわけじゃない）
・モデル部分の管理
各ビジネスモデルは、それぞれ作るにしても、それを管理する部分に
フレームワークを使う。DIなんか・・
・データベースアクセス
データベースアクセス部分にフレームワークを使う。
DAOを使ってアクセスする。
O/Rマッピングなどを行うもの
という部分に、どんなフレームワークを当てるか？ということを考えます。
なお、この全部を、１つのフレームワークで行う場合、
「フルスタックフレームワーク」といいます。
■たとえば・・・
ビュー → コントロール：Struts
モデル部分の管理 ：Spring
データベースアクセス ：Hibernate
など。この場合、Strutsを使うと、JSPなので、Web用のブラウザで見る場合はつなぎやすいけど、
AJAXをやる場合、つなぎにくい（出来ないわけではない。十分出来るんだけど、もっとふさわしい方法がある）そこで
ビュー → コントロール：T2フレームワーク
モデル部分の管理 ：Spring
データベースアクセス ：Hibernate
とかも、ありえるかもしれない。
このように、GUIとかによって、フレームワークが変わってきたりする。
もちろん、フレームワークを作るとか、使わないという選択肢もあるが、自作する、使わないということを、この場で、「決める」ことになる。
アクセス
トータル
ランキング
