開発の初めから順番に書いていってみる その７４：テスト（３）手順の概要

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

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

　今、テストについてやっています。今日は、手順の概要です。

---

■手順の概要

　実は、手順の概要については、前回書きました。
　こんなかんじです。

　　　　テスト仕様書作成
　　　　　　↓
　　　　テスト環境構築
　　　　　　↓
　　　　テストデータ・ドライバ、スタブ作成
　　　　　　↓
　　　　　テスト
　　　　　　↓
　　　　テスト結果作成

---

■では、単体、総合、結合で何が違うのか？

　でも、テストを、単体、結合、総合と、３つに分けて書きました。
　手順は同じなのに、何が違うのか・・・というと、

　まず、前回、テストの入出力について書きました。

●テストの入力は
・テストする対象
・テストする事項が記載されている仕様書
　　→テストレベルにおいて、対象となる仕様書は、
　　　ちがいますが）

●出力は、
・テスト仕様書と結果報告書（成績書）
・エビデンス

ってことでした。

ここで、書いてあるように、テストする内容＝対象となる仕様書が違います。
そのため、調べる対象も、変わってくることになります。
つまり、同じプログラムでも、単体・結合・総合でテストする内容が違うのです。
　で、その違いから、テスト仕様書項目が変わり・・・ということになってきます。

---

　どうちがうのか・・・

　ということに関しては、手順とは違う話なので、次回以降に書いていきます。

オブジェクト指向で開発の最初から最後までの手順例－その２０：クラスの決定。

　オブジェクト指向でやる場合の最初から最後までの流れを、実際の例を挙げて書いていくシリーズ「オブジェクト指向で開発の最初から最後までの手順例」、いままでで、要求仕様がまとまり、前回で、要求定義書で出てきた、やることとエンティティを全部まとめました。
　ここの予定で行くと、次は、「やることをメソッドとして適切なエンティティにいれ、モデル部分のクラスをつくる」です。

---

■クラスにするには。。

クラスにするには、
・メソッドを全部出す
　　→前回の「やること」がメソッドにあたります。

・エンティティをクラスとする
　　→前回挙がっているエンティティをとりあえず、クラスとします

・メソッドをクラスにいれていく
　　どのクラスに入れるかの基準

　　　第一順位　そのメソッドのやることの対象のクラスに入れる
　　　　　発注データを編集する＝＞対象は「発注」：発注クラスへ

　　　第二順位　そのメソッドを行う人に入れる
　　　第三順位　メソッド自体をクラスにしてしまう
　　　第四順位　テキトーに入れておく

　　こんなかんじで、テキトーにきめる（結局、テキトーかい（＾＾；）

・エンティティの項目を属性として、クラス図をきれいに書く

・メソッドの引数を決定する
　　→ただし、カオル姫方式で、とりあえず、引数ハッシュにいれる
　　　という手もある。

---

■今回は・・

　ってことで、今回は。。。
　前回、エンティティごとにやることを書いてしまったので、
　もう、できてますね。

　あとは、あれをきれいに書きましょう。

　今回は、引数を、ハッシュマップにしておきましょう。
　全部（いいかげんだなあ　（－＿－；）

---

　ということで、モデルはできたことにします
　（ってことは、javaで、中身空っぽで、クラスが書けるってことです）

　次回は、「フレームワークを決定する」です。

DBアクセス自動生成のためのトランザクション処理方法

　いま、シリーズ化している「オブジェクト指向で開発の最初から最後までの手順例」で、そのうち、トランザクション処理が必要になってくるはずです（発注と発注明細）。

　そこで、そのための「トランザクション処理方法」に関して、先回りして書いておきます。

---

■そもそも、トランザクション処理とは

　トランザクション処理とは、複数の更新、削除、挿入処理を行うとき、すべての処理が成功したときだけ、その処理を実行し、一個の処理でも失敗したら、全部の処理を取り消して欲しい場合に使います。

　すべての処理に関連がある場合などでは、必須の処理となります。

　今回の場合、発注データ挿入に失敗したら、発注明細をキャンセルしないといけないし、逆に発注明細の挿入に失敗したら、発注をキャンセルしないといけないです。なので、発注と発注明細の間にトランザクション処理が必要です。

---

■一般的方法

　複数のテーブル間の処理のため、トランザクション処理のスタートと終了（コミットやロールバック）は、個々のテーブル内(EJBだとエンティティBean)で行うのではなく、

　その個々のテーブル操作より上の、複数のテーブルを操作する呼び出し部分（EJBだとセッションBean)で行います。

　一般的に、以下の手順で行います

	・コネクションを作成します

		・個々のテーブルで、更新処理をします
		・エラーが起きたら、トランザクションキャンセルし、
		　コネクションをクローズして、更新処理を終了します
				：
			（以降、更新分、この処理をします）
				：

	・コミット処理を行い、失敗したらロールバックします
	　いずれにせよ、コネクションをクローズします。

　各テーブルの更新処理においては、初めに作成したコネクションを受け渡しして、それを使って、更新、削除、挿入などの処理をします。このコネクションなど（ステートメントまでももっておいてもいいし、検索用にPreparedStatementを持つ場合もあります）は、Contextクラスというのを自分で作って、そこに入れるのがふつうです。

---

■トランザクションの入れ子の問題

　ただ、呼び出し部分＝MVCだとモデル部分のメソッド全部にトランザクション処理を入れると、モデルの中で、モデルを呼び出している場合、トランザクションの入れ子になってしまいます。

　入れ子処理ができるものもありますが、そもそも、自分で何がどーなっているのかわかんなくなってくるので（ウィリアムのいたずらが頭悪いだけ　＾＾；）
　入れ子処理をさせないほうがいい場合もあります。



　この対応としては、コンテキストの中身がNULL(トランザクションスタートのとき）は、コンテキストを生成し、生成した場合は、そのモジュールで、commitまたはロールバックします。

　逆に、コンテキストの中身に、コネクションなどが入っていたら、それは入れ子ということで、そのコネクションを使って、処理を行い、エラーがきたら、返り値にエラーを返して抜けます（エラーを受け取り、ロールバックするのは、呼び出し側の仕事）

---

■そこで、カオル姫方式を使う

　現在、自動生成しているDBアクセス部分は、ハッシュマップを引数にしているので、こいつにコネクションを入れます。

　呼び出し方のモデル部分も、入れ子の場合、コネクションを受け渡しすることになります。
　ただ、面倒なので、モデル部分の引数を、ハッシュマップにしてしまえば、DBアクセス部分同様、ハッシュマップにコネクションが入れられます
（コネクションが入ってないハッシュマップだった場合、それが一番の上位になるので、そこで、コネクションを生成して、ハッシュマップを作ります）

---

　詳しい話というか、具体例は、「オブジェクト指向で開発の最初から最後までの手順例」の該当箇所で書く予定です（今後）