オブジェクト指向で開発の最初から最後までの手順例－その２５：フレームワークその５

　オブジェクト指向でやる場合の最初から最後までの流れを、実際の例を挙げて書いていくシリーズ「オブジェクト指向で開発の最初から最後までの手順例」、今、ここの「（３）フレームワークを決定する」をやっていて、前回「何を作るのか？」をまとめました。

こんなかんじ

１．画面
　　　・各画面
　　　★共通部分（呼び出し部分など）

２．コントローラー
　　　★サーブレット
　　　★返り値となるXMLのJSP

３．モデル部分
　　　・各モデル部分のプログラム

４．DBアクセス部分
　　　★各アクセス部分
　　　★共通部分

　今回は、「２．コントローラー」について説明します。
　（今回、この「２．コントローラー」を修正します）

---

■コントローラー部の概要

コントローラー部の概要に関しては、ここに書いたように、

１．セッションと引数を全部、ハッシュマップに入れる

２．そのハッシュマップをもとに処理を行い、
　　　　処理系なら、処理結果
　　　　検索系なら、検索結果のベクタ（ハッシュマップのレコードが要素）
　　をうけとる

３．以降の処理で必要な値は、ハッシュマップから取り出し
　　セッションにセット

４．XMLを書き出す（WebAPIの場合）
　　　　JSPを呼び出す

ということです。以下、それぞれの内容について考えて見ます。

---

■セッションと引数を全部、ハッシュマップに入れる

これは、どのサーブレットでも、全部同じように、
ここの「セッションとパラメータをすべてハッシュマップに入れる」で書いたプログラムで、できそうです。

なお、かりに、１つ１つ、必要な値やセッションをとってくる場合でも、
WebAPIの仕様書をExcelで記述して、そこから自動生成すれば、
まあ、OKです（自動生成の方法は、ここ）

---

■そのハッシュマップをもとに処理

　まあ、自動生成するとして、そのWebAPIの仕様書に、呼び出しモデルのクラスとメソッドを書くこととします。

　返り値が、処理系と検索系で違うので、雛形を２つに分けることとします。

---

■以降の処理で必要な値は、ハッシュマップから取り出しセッションにセット

　ハッシュマップのキーsessionDataに、ハッシュマップに入れたいデータをすべて入れておくとして（入れるのは、モデルで入れる）、

　ここでやるのは、以下のとおりです

・ハッシュマップから、キーsessionDataの値（これもハッシュマップ）を
　取り出し、変数sessionMapにいれます
・sessionMapのキーと値を全部取り出し、セッションにセットします。

---

■XMLを書き出す（WebAPIの場合）

　サーブレットの返り値をつくるのですが、方法は
　　フォワードしてJSPで値をつくる
　　そのままgetWriterを取得し、どんどん出力を書いていく

　の２とおりあります。前者のつもりで、いままでJSPと書いていたのですが、
　どうも、処理系、検索系の雛形を用意しておけばOKそうなので、わざわざフォワードしなくても、サーブレットの雛形にそのまま書けばいいかな・・

　ということで、JSPは用意しないで、サーブレットを用意することにします。

---

ということで、「★返り値となるXMLのJSP」はいらないので、作るものは、こういうふうになります。

１．画面
　　　・各画面
　　　★共通部分（呼び出し部分など）

２．コントローラー
　　　★サーブレット	＝＞雛形と仕様書を用意

３．モデル部分
　　　・各モデル部分のプログラム

４．DBアクセス部分
　　　★各アクセス部分	＝＞雛形と仕様書を用意
　　　★共通部分	＝＞プログラムを用意

ということで、次回は画面です。

開発の初めから順番に書いていってみる その８３：単体テスト（８）バグ修正概要

シリーズ「開発の初めから順番に書いていってみる」の続きです。

　設計手順には、要求分析、外部設計、内部詳細設計・プログラミング、単体テスト、結合テスト、総合テスト、運用テスト及び運用とあります。
　（バックナンバーは、ここ　http://www.geocities.jp/xmldtp/index_kaihatsu.htm）。

　前回で、ここの順番で言う「４．実際にテストする」が終わりましたので、今回は次の、「バグ修正して再テスト」です。

---

■バグ修正の一般的な流れ

　テストで障害が起きたり、なんらかのはずみでバグを見つけてしまった場合は、イカのような形で、バグ修正するのが、一般的だと思います。

１．バグ発生内容を特定し、エビデンスをとる（とれたら）
２．バグ票に記入
３．台帳に登録、担当者にバグ票を送付
４．担当者がバグ修正
　　　　・バグの原因特定
　　　　・修正
　　　　・確認テスト
５．担当者がバグ票の障害修正欄などいろいろ記入する
６．バグ発見者にバグ票が戻ってくるので、確認
　　　　→OKなら、７へ、NGなら、４へ
７．修正確認をバグ票と台帳に記入、バグ票は保管
８．デグレードしていないかのリグレッションテスト

ということで、ここでの成果物＆入出力は
・バグ票（＋添付資料のエビデンスなど）
・バグ管理台帳
ということになります。

---

■バグ票、管理台帳と、バグトラッキングシステム（BTS)

　で、バグ票、管理台帳ですが、紙でやる場合は、こんなかんじですが（まあ、これを、特に管理台帳をExcelやAccessなどでやるという話はありますが、それもふくめて）、このようなバグ票、管理台帳を電子化したものが、バグ管理システム（＝バグトラッキングシステム、BTS)となります。

---

■リグレッションテスト、回帰テスト

　で、バグ修正したときに、修正箇所はなおしたんだけど、今度は他のところに（今までちゃんと動いていたところに）バグを入れてしまうということがありえます。これをデグレードといい、これを防ぐため、すでに行ったテスト項目を、再度確認することをリグレッションテスト（あるいは回帰テスト）といいます。

　これは、2度手間、３度手間・・になるので、いかに自動化して、品質をおとさずテストするかというのが、鍵になります。

---

■横並びチェック

　あるバグがあったとき、同じモジュールを通るところは、同じようなバグがでるはずです。そして、そのモジュールを直せば、同じようなバグも修正されるはずです。
　また、同じモジュールではないけど、同じようなコーディングをしているときも、同じようなバグがでるはずです。そういうところは、そのようなコーディングしてるところ全部を直して、修正しなきゃいけません。

　このように、あるバグに対し、同じ原因によって、似たようなバグが出ている、出る可能性がある場合、修正して、その似たようなバグが出ているところも、直っているかどうか確認（チェック）する必要があります。
　これが、横並びチェックです。

　横並びチェック項目に対し、あらたにバグ票を発行するか、同じバグ票でやるか、同じバグ票に横並びチェック項目を入れるかは、プロジェクトによって違います。
　

---

　ということで、バグの概要は書いたので、次回からは、個別にいくつかのテーマを詳しく書いてみたいと思います。