テストファーストとか、ＸＰとか言うのであれば、ユーザーが理解できる業務の流れ図から、Javaのwebアプリやサーブレットができることを証明（手順を示す）しないと、いけないよね。
サービス指向、ユーザー中心指向とか、出てきてるけど、それも同じ。
でも、誰も書いてない気がするんだけど・・・
しかたない。ここで、書いてあげよう。
流れ図は、
ＥＡポータルにある業務流れ図（ＷＦＡ）の
http://www.meti.go.jp/policy/it_policy/ea/gainen/product/wfa/1.html
を使う。
■業務流れ図→サービス（サービス指向）
サービス指向であれば、サービスを出してくればいい。
サービスは
（１）コンピューター処理がサービスになる。
・受講者リスト作成
・アンケート分析
・（テスト結果）登録
（２）画面中、（１）の処理を経ないのに、ＤＢ，帳票に書き出しているもの
・民間企業参加申し込み＊
・省内参加申し込み＊
・研修担当受講者募集
・受講確認登録
（テスト結果登録画面は、上に登録がある）
＊レーンが違う（対象者が違う）場合は、分けておいたほうが無難
（３）帳票中、（１）、（２）の処理を経ていないのに、ＤＢ書き出し、帳票出力してるもの
・アンケート記入？（アンケート分析とは違う処理）
・テスト結果出力
（受講者リストは、（１）の受講者リスト作成）
これを、サーバー側のサーブレット（ないしはstrutsのaction）とする。
したがって、以下のサーブレットクラス（ないしは、actionクラス）が出来る。
・zyukoListSakusei
・questionToroku
・TestResultToroku
・MinkanSanka
・ShonaiSanka
・TantoZyukoBoshu
・ZyukoKakunin
・questionKinyu
・TestResultShuturyoku
英語ローマ字まじりですみません。
■業務流れ図→画面（サービス指向・ユーザー中心）
そのクラスが呼び出す画面は、
（１）コンピューター画面
・民間企業参加申し込み
・省内参加申し込み
・研修担当者受講者募集
・受講確認登録
・テスト結果登録
（２）帳票から入力になっている
・アンケート記入
これらの画面には、ボタンがついて、そのボタンから、対応するサービスを呼び出す。
ということは、そのサービスで必要な情報が入力画面になる。
なお、そうすると、「帳票が出力になっている」ものには、画面がないことになる。
これは、プログラムを起動すればよいだけなので、それらのボタンをどこかにつける（他の画面につけるか、１画面にまとめるか）。そして、ボタンが押されたら、対応するサービスを呼び出す。
これを、ＨＴＭＬなり、ＪＳＰなりで書く。
Ｓｔｒｕｔｓの場合は、ＡｃｔｉｏｎＦｏｒｍクラスを用意する（中の項目はあとで決める。クラスだけ用意）
これが、クライアント側で操作する画面になる。
■業務流れ図→帳票（サービス指向・ユーザー中心）
これは、図の帳票をまとめればよい
・受講者リスト
・アンケート
・テスト結果
場合によっては、画面で代用可能なときがある（アンケート？、テスト結果？）その場合には、書かない。
帳票はcocoonで出すなら、xmlとか、そーいうのが必要になってくる。
実装によって違う。
ただ、クラスから呼び出すことは確かなので、上記で作成したクラスのところに入れておく。
■業務流れ図→ＤＢ
図に描いてあるファイル
・研修募集ファイル
・受講者ファイル
・人事記録
これを、まず、テーブル作成して、Hibernateを使うなり、アクセスモジュールを作成するなりして、図中、入出力しているサービスがあれば、上記クラスから読み書きする。
■業務流れ図→サービス出力データ
サービスとしては、入力項目は、ＳＯＡＰかＲＥＳＴかで変わる。
出力項目は、ＸＭＬ出力にしたほうが無難ではある。
がＳｔｒｕｔｓだと画面になっちゃうのかな。
具体的な項目については、後述の「データの決め方」で決まる。
■業務流れ図→ユーザーごとに画面、帳票をまとめる（ユーザー中心）
あとは、図のレーンごとに画面、帳票をまとめ、ユーザーが使いやすいように、あーだコーダしてくれ。
■データの決め方
１．まず、帳票出力、画面出力項目をきめる。
２．そうすると、ＤＢ保存しなければいけない項目が決まり・・・
３．そうすると、入力しないといけない項目が決まるので、画面に追加
なので、帳票・画面出力→サービスクラス出力→ＤＢ→サービスクラス入力→画面入力
という順に派生してなおしていく。
こんなかんじで、業務「流れ図」から、サービス指向のサービスと、ユーザー中心指向で検討される画面等との関係が説明できる。
アクセス
トータル
ランキング
