前に、要件から、クラス図までに落とし込む流れを書いたとき、これは、MVCでいうモデルに相当すると書きました。
で、MVCのコントローラーについては、MVCで要件→モデルのクラス図から、コントローラーに落とし込むで書きました。
ということで、残りのView、画面についてです。
■画面とコントローラーの関係
コントローラーで、StrutsならAction、サーブレットならサーブレットクラスで定義されたところ（＝モデルの画面用メソッド）は、画面のなんらかのアクションに対応し、そこで呼び出されないといけません。
つまり、サーブレットのクラスは、ボタンを押すと呼び出されるとか、画面が書き出されたとき（ロード）呼び出されるとか、なんらかのイベントに対応して、呼び出されます。多くは、ボタンに対応します。
■画面とクラスの対応は、方針によるが・・・
画面とクラスの対応は、その設計方針によりますが、１画面１クラスを割り当てると、楽かと思います。
■問題は、画面と、コントローラーを呼び出すイベントの関係
で、問題は、画面と、コントローラーを呼び出すイベントの関係です。
これにより、画面割が変わります。。。
が、これ、
コントローラーを呼び出すイベントが起きる時点で、そのコントローラーに 渡す値すべてが、どこかで入力されていなければいけない （＝そうしないと、入力が足らなくなる） |
ということ以外は、好き勝手にできます。
たとえば、１画面しか作らないで、そこに全部の情報を入れる、ログイン名もパスワードも、入力情報も出力情報も・・・っていうことは、可能ではあります（現実的ではないけど）
逆に、１つ入力されるごとに、１画面というのもありえます（対話型の入力の場合、ダイアログがどんどん出る形とか、チャットしてるようなかんじで実行する）
■とはいえ、標準形はある
とはいえ、大体世の中のおとしどころといいますか、標準形はあります。
要件のとき、
何々が、何々を、どうする
というかたちで、主語（＝人）、目的語（＝対象物）、動詞（アクティビティ）という形で書きました。なので、今回も、
まず、主語を確定する
＝＞ログイン画面で、操作している人を決定＝この人が主語
そのものを表示するが、
複数あり、検索が必要な場合は、
（検索）一覧画面（検索は画面をわけることもある）
詳細画面
検索が必要ない場合は、
詳細画面
になります。
そして、データ入力・編集では、CRUD,つまり、新規作成、検索、編集、削除が必要なのですが、一覧画面がある場合、そこから削除、新規作成、編集がある場合が多いです（編集は、一覧リストをダブルクリックのケースもあります）
検索は、検索画面があるところに、検索実行ボタンがあります。
検索画面と一覧画面が分かれているときは、一覧画面を出し、そうでないときは、検索結果を一覧にセットします。
一覧画面にある、新規作成、あるいは編集のイベントが起こると、詳細画面が表示されます（編集の場合はそのデータがセットされ、新規作成の場合は初期値）入力されると、登録等のボタンが押されて、新規作成、編集の処理に行きます。
削除のとき、内容確認をかならずさせるために、一覧でなく、詳細のほうにおく場合もあります。
だいたい、こんなかんじで画面割りは行われます。
ということで、このシリーズ？の話、おしまい。
アクセス
トータル
ランキング
