13.データベース設計
会話の背景：
詳細設計のもう一つ重要な作業はデータベース設計である。
データベース設計の目的永続的なオブジェクトをどういう風にデータベースに格納したり、アクセスしたりするかを決定することである。そのため、データベースのスキーマ、あるいはテーブルおよび項目やタイプの定義、テーブル間の関係、テーブルの正義か、および検証ルールなどを検討しなければならない。
登場人物：
鈴木―PL
山田、田中―PG
会話：
鈴木：おはようございます。
今日はデータベースの設計について、これからの作業をどう展開するかを話したいです。
田中：現時点ではクラス設計が終わったところで、ここまで、われわれは大抵データベース設計をあとまわしにしましたが、今ではもう遅いのではないでしょうか？
鈴木：詳細設計ではクラス設計とデータベース設計両方とも不可欠な部分です。どちらを咲きにするかはシステムの性格によると思います。
一般的にいうと、もし帳票や入力、また照会が多いシステムならば、データベースの設計が先行したほうがいいかもしれません。一方、ビジネスロジックが複雑な場合はおそらくクラス設計を先にしたほうがいいと思います。実はどちらにしても、相互の関係があるので、ある程度くると、並行的にまた反復型に改定されて行くと思います。
田中：そうすると、今できたクラス設計の中のエンティティクラスをテープルの候補と考えればいいでしょうか？
鈴木：基本的にはそうです。ここでは、判断の条件はそのエンティティクラスが永続的なのもであるかどうか。それに基づいて論理データモデルが設計できます。言い換えると、一つの永続的なエンティティクラスを一つのテーブルに対応させます。
山田：それで、クラスの属性とテーブルの項目およびそのタイプをどうすればいいでしょうか？
鈴木：われわらが設計したクラスはオブジェクトの世界で、データベースはリレーションナルの世界なので、その間をまったく同じ用にマッピングするわけではありません。たとえば、Javaでは、Stringというタイプがありますが、データベースに対応すると、そのタイプはおそらくCharまたVarCharになると思います。
また、クラスの一部の属性は構成できる属性であることがあります。それらはデータベースに反映しなくてもいいです。例えば、年齢というものが生年月日から構成できます。これはクラス設計上でおそらくビジネスからの理由でこの属性を持つ必要があるが、それをデータベースにもわざわざ項目として作る必要はほとんどありません。
山田：そうですか。
それと、クラスの関係、たとえば汎化（はんか）関係や1対ｍまたｍ対ｎの関係などをどうすればよろしいでしょうか
鈴木：それはリレーショナルデータベースなので、主キーの候補を考えないといけない。それを考えると、たとえば、汎化関係の場合は、同じ主キーを持つ場合は、汎化関係にあるクラスはスーパークラスとサブクラスがあるが、サブクラスの属性をスーパークラスの属性とあわせて一つのテーブルの項目にすることもあるし、また別々のテーブルにする可能性もあります。
また、1対ｍの関係を持つクラスに対しては、大抵普通のテーブルで設計すればいいでしょう。Ｍ対ｎの場合はほとんど関連付けための一つテーブルを追加したほうがいいと思います。とにかく、関係を反映するため、必要に応じて新たな主キーや外部キーを作ることはたびたびあります。
山田：そうですか。
鈴木：それと、今回設計するシステムは外部システムからデータを読み出すことがあります。あれは、外部システムのテーブルより落としてもらうものですから、直接使うといろいろな不便があるかもしれません。その時には、ストアードプロシージャーによりビューを作ることが必要になります。これらのビューの設計も今回データベースの一部になると思います。
田中：わかりました。ビューの設計もちゃんとやりますから。ところで、最近ORMという言葉をよく耳にしますが、あれもデータベース設計にも関係あるのでしょうか？7
鈴木：ORMとはObject-Relational Mappingの略で、これはオブジェクト世界とリレーショナル世界とうまくマッピングすることで、コーディングに生産性をあげる方法論とツールです。本来はプログラミングと直接関連していますが、データベースの設計にはあまり関係ありません。といっても、いまのORMツールはクラスからテーブルへ、またテーブルからクラスへの連動ができていますので、われわれが設計したデータベースがある程度定まってから、ORMツールを導入すれば、これからの微調整やメンテナンスには役立つと思います。
山田：最後に、今回の成果物はどうなるでしょうか？
鈴木：今回のデータベース設計には、以下のことを念頭においてほしいです。
まずは、もちろんテーブルのスキーマです。そのスキーマとはテーブルの各項目の名前、タイプ、サイズ、主キー、外部キー、また空にできるかどうかなどを記述すべきです。
テーブル間の関係はツールを使って、ER図を書く必要があります。
また、もし画面ごとに、入力のために検証することがある場合は、これらはほとんどテーブルの項目と対応していますので、ぜひその検証ルールを記述してください。
最後の最後、まだ早いかもしれませんが、テスティングのことを考えると、サンプルデータを早めに用意したほうがいいと思います。大抵（たいてい）サンプルデータを準備するときには、データベースの定義の正しさが検証され、矛盾などを検出することもできると思いますから。
皆：わかりました。
鈴木：そうでしたら、さっき言った成果物をゴールとして作業をお願いします。今日のミーティングはここまで終わらせましょう。皆さん、ご苦労様でした。
１４．テストを計画する
会話の背景：
詳細設計が終わると、テストを計画することができる。テストとは、単体テスト、機能テストと統合テスト、またパフォーマンステストなどがある。計画段階では、テストの範囲、リポートの項目、およびテストの期間と要因などが決まる。
登場人物：
石田― PM
鈴木― PL
山田、田中― PG
会話：
石田：こんにちは。
さて、詳細設計がそろそろ終わり、これかコーディングに入りますから、この二つのフェーズをはさんで、テスト計画をするため、皆さんと相談しよう。
田中：われわれは、普段はコーディングが終わってからテストしますので、現時点で計画するのは、早いのではないでしょうか？
鈴木：そうですね。これまではそうでしたが、これからわれわれのチームはテストを強化したいので、コーディングする前に計画したほうがいいと思います。ここでは、テスト計画としては、具体的にいうと、テストの種類、テストの内容と範囲、またテストリポートの項目などについて議論してください。この計画ができたら、コーディングしながらテストも早めに実施できるので、開発の質を高めることを期待しています。
石田：その通りです。
テストとは、単体テスト、機能テストと統合テスト、またパフォーマンステストなどあります。今日はそれぞれに関して計画してみましょう。
鈴木：それでは、まず最初はもちろん単体テストです。
単体テストはホワイトボックスのテストで、基本的には各プログラマーにやってもらいます。自分が開発したものを、クラス単位で、ちゃんと仕様通り動いているかを確信しなければなりません。
単体テストの内容は、原則としては、パブリックなインターフェースを全部テストする必要があります。
山田：テストの内容はパブリックなインタフェースとおっしゃいましたが、何か注意点があるでしょうか？
鈴木：そうですね。単体テストを計画するときに、正常系はもちろん考えないといけませんが、異常系のテストはもっと大事だと思います。
例えば、パスワードを英数字として定義しましたが、もし変な文字を入力したら、どうなるか？また英文字を入力するときには、定義以外の文字、例えば、シングルクォーテーション（「’」）を入力したらどうなるか、いろいろテストケースにいれる必要があります。
山田：単体テストには、今回もJunitを使いますか？
鈴木：そうです。今回もJunitを使います。その理由は、Junitを使うと、テストが自動化ができますから。最初書く時には時間がかかりますが、一旦書いたら、何回もテストできますから。
また、単体テストでも、その中でエンティティクラスのテスト、画面クラスのテスト、ビジネスフロークラスの側面があります。ここまでの経験ではJunitはドメインクラスには一番適切ですが、ウェブ画面のテストはHttpUnitなどのツールを使ったほうがいいと思います。最後にコントロールのようなActionクラスにはStrutsTestCaseを使ってみてもらいます。
田中：機能テストと統合テストはどうなるでしょうか？
石田：機能テストと統合テストは基本的にはブラックボックスなので、ユースケースをベースにして、各関連画面をはじめ、ビジネスロジックおよびデータベースの結果を比べながら、テストを行うことを想定しています。
そのため、テスト要員はいまからテストプランを書く必要があります。原則としては、単体テストと同じように、正常系と異常系のケースをいくつか用意しなければなりません。また、今回はウェブシステムなので、ウェブ上で同時実行が相当あると思います。そのため一部の機能に対して同時実行のテストケースも計画しておいてください。
鈴木：それと、今回のパフォーマンステストはどうでしょうか？
石田：パフォーマンステストはウェブシステムにとって大事です。通常、開発するときには、プログラマーが自分のマシン上でウェブサーバーやデータベースも置いていますので、パフォーマンスの問題は気にしないと思います。しかし、実際のウェブサーバーに入れると、例えばISに本番のマシンを置くと、状況がぜんぜん違うことが多いです。それこそ、ISPの本番のマシン上に置いたシステムに対してパフォーマンステストが必要だと思います。パフォーマンステストは特定のツールを使って、出来上がったシステムに対して、同時に何百何千回のアクセスをするようにしミューレーションします。最近のパフォーマンステストツールは、仮のサーバー上でもちろんテストできるし、導入した後の本番のサイトでも、テストすることができると思います。
鈴木：それはわかりました。
ただし、前回の経験によると、ちゃんとテストするには、時間と要員がかかるので、プロジェクト管理の面では、サポートしていただきたいです。
石田：そうですね。今回は、単体テストのため、各プログラマーにはコーディング時間を通常の1.5倍に延長しようかと考えます。機能テストと統合テストは、コーディングをしながらやりますので、できれば、少なくとも一人の専業テスターを用意します。パフォーマンステストは大抵コーディングが終わる時点なので、その時点になると、プログラマーから一人か二人をまた追加して、やってもらいたいですけど。
鈴木：それならばいいと思います。
石田：それでは、今日のテスト計画に関するミーティングは終了します。皆さん、お願いします。
皆：よろしくお願いします。
没有评论:
发表评论