シリーズ「開発の初めから順番に書いていってみる」の続きです。
前回、要求分析の結果（ここではDFDを扱います）から、外部設計、最終的に詳細設計へ落とし込むのは、以下の手順で行うと、説明がつくということを書きました。
（１）入出力の媒体をきめる。
（２）その媒体ごとにフレームワークを決定する。
なければ、入出力方法を決定する。
（３）そのプロセスの起動方法を考える
なければ、起動モジュールを考える。
（４）起動モジュールから、（２）の呼出し手順を考える
→そうすると、処理部分だけ、のこるはず。
（５）その処理部分をどうするか、考える。
（６）そうすると、細分化された入出力、処理部分ができる。
ここで、あわせたいものは、あわせる
→特に画面を、いくつか合わせて１画面にすることが多い
（７）処理部分を、ワーカーさんに渡せるまで落とし込む。
前回はは、（１）から（５）までです、
今回は（６）を説明します。
■細分化された入出力をあわせる：画面以外
さて、（５）までで、１プロセスにたいして、入出力部分と、プロセス処理部分に分離しました。
でも、入出力にはフレームワークがあるか、それ相応のものをつくるとなると、１プロセスに対してあるのではなく、たいていは、DBなら１テーブル、帳票なら１つの画面に１つのプロセスがあって、そのプロセスを、プロセス処理部分が呼び出すっていう形になると思いますので、そうやって、書き換えましょう。
つまり、要求仕様段階で、
っていうことです。この（６）までの工程で。。
（５のとき、プロセスごとにいったんなるので、もっと細かくなるが、まとめると、結局こうなる。。まあ、面倒なので、ふつう（５）の時点の図を描くことはない）
■細分化された入出力をあわせる：画面
画面は、Action１個に対して、いろいろ操作しましたが、１アクションは１画面ではない、つまり、ボタン１個が１アクションに相当するのですが、１画面でいくつものボタンになることがあります。なので、まとめます。
たいてい、エンティティ１個に対し、それが複数あるなら、
一覧（エンティティのリスト）と、詳細画面（１エンティティ分）があって、そのエンティティに関連するアクションを１ボタンとしてまとめると、うまくいきます。
まあ、こんなかんじで、まとめた画面と、その画面の流れを、画面定義書としてまとめます。
そーすると、最終的に、こんな図に変換されると思います。。。
なお、黄色の部分が画面のプロセスになります。
Strutsだと、ActionFormとJSP、Javascriptなんかで記述するプロセスっていうことになります。
■つまり
つまり、入出力フレームワークに沿ってまとめるということです。
こうなると、結果として、入出力のものは、全部プロセスに対する値渡しになるので、
入力からプロセスをへてわたってきた値を、
なんらかの処理をして
値を渡すとプロセスを経て出力する
そうすると、処理部分の話だけになります。
で、次回は
（７）処理部分を、ワーカーさんに渡せるまで落とし込む。
の話になります。
アクセス
トータル
ランキング
