１７．テストリポート、バグリポートと変更連絡票 １８．リリースの準備

１７．テストリポート、バグリポートと変更連絡票
会話の背景：
コーディングに入りますと、それに伴ってテストも始まる。
テストをすると、テストリポートや、バグリポート、および変更連絡票などが発生する。これらのドキュメントの規約も関係者のあいだで意識をさせて、共通な行動を行うよう、努力が必要である。
登場人物：
石田―　PM
鈴木―　PL
山田、田中、前田―　PG
会話：
石田：こんにちは。
現在コーディングに入りまして、テストも徐々に始まります。それにより、テストレポートや、バグレポート、および変更連絡票などが発生しますので、今日はテスター、SE、プログラマーにも集まってもらって、これらのドキュメントの規約などに関して議論してもらおうと思います。
鈴木：そうですね。まずテストリポートからはじめましょう。
ここで言うテストは機能テストと統合テストです。われわれはテスト計画通り、自分が担当しているところの機能をちゃんとテストしなければなりません。その結果をテストリポートとして書いてもいます。テストリポートでは、まず、見出しの部分には、テスターの名前を書いてください。それと、テスト対象となるモジュールの名称、バージョン、テスト環境、データベース環境および使っているデータベースの名称、それと関係している外部のシステムなどを記述してください。
そのテストの内容としては、各テスト項目は一行になると思います。あるモジュールに対してのテストはまとめて一緒においておく。各行には、番号、テスト機能、テスト対象、テスト内容、予想結果（画面変化、データベース変化など）結論、注釈、バグの重要度などがあります。
山田：今回のテストでは、自動的な管理ツールをつかいますか？
鈴木：今回は、自動的な管理ツールは使いませんので、Excelフォーマットを記述してください。その上で、もしハイパーリンクで、テスト結果の間（あいだ）に、また関係の項目間（あいだ）を連結できればベターだと思います。
山田：わかりました。バグリポートはどうでしょうか？
田中：バグリポートはテストリポートからとってきますが、エラーが出た項目をそのままコピーしてくることはいけません。バグリポートは開発者あるいはプログラマーにフィードバックするので、各バグに関して、以下のような項目が必要です。
バグ番号、バグ現象、発見者・テスター、対応したテスト番号、改修優先度、など。このバグリポートをチームリーダーに渡して、リームリーダーより、作業の指示として関係するプログラマーに配布します。
石田：おそらく、コーディングに入っても、お客さんの都合により仕様の変更、また不具合により仕様の変更をすることがしばしば発生します。それらの仕様変更などに関してもドキュメントを書いて、ちゃんと管理しなければなりません。
鈴木：そうですね。一部はバグともいえますが、実際は仕様が曖昧とか誤っていたこともあります。またユーザーが新たな要求を出してくるこももあります。この場合は、大抵SEが関係者と相談し、変更連絡票を書くことが必要です。
変更連絡票には、以下の項目が必要です。
変更連絡票番号、現状、新たな要求、関係した機能、変更優先度、など。
ほとんどの場合は実際的には新しい仕様ですので、ここまでの要求定義と同じように、必要な画面設計や、機能フロー図、またビジネスルールなどの補足情報を添付することが必要です。
前田：そうすれば、コーディングのほうは、これらの仕様変更に従って、新たな作業をしなければならないでしょうか？
鈴木：基本的にはそうですが、全部ではありません。
ということは、バグリポートでも、変更連絡票でも、仕様変更でも、チームリーダーがチェックすることが必要です。これらがもたらす問題点は全部が一気に解決できるわけではないので、やはり優先度により、重要性、まだ既存システムの変更の大きさにより、計画しなければなりません。
おそらく、一部はプログラマーに戻して、改修や新規機能として作業してもらいますが、一部は時間や資源、また予算の制限で、すぐやれないかもしれません。それと、ユーザーの要求は、ここでもまだはっきりしていないこともよくありますから。
田中：その時は、ペンディングリストを作ることになると思います。このリストは、今すぐやれないですが、やってほしいことを記述しておきます。ペンディングリストは変更連絡票と似ていますが、およそ以下の項目が必要です。
ペンディング番号、提出者、提出日、概要、ペンディング詳細、ペンディング理由、関係した機能、作業優先度、など。もちろん、変更連絡票と同じように必要な補足情報を添付することもよくあります。
石田：ことろで、今回の開発では、バグ管理、変更管理には何かツールを使うでしょうか？
鈴木：本来はツールをつかりですが、ただし、今回はEclipseをはじめ、StrutsやHibernateなどフレームワークもあるし、皆さんには勉強することがいっぱいなので、テストやバグのほうはとりあえず手で管理するになっています。
次回のプロジェクトでは、BugzillaかGNATSなどオープンソ系のバグ管理ツールを使う予定です。
石田：了解しました。それでしたら、今日のミーティングはここまでで終わらせましょう。

１８．リリースの準備
会話の背景：
リリースすることは出荷することと似ている。お客さんにシステムを納品することである。ただし、開発プロセスが反復型開発プロセスの場合はリリースが何回かあるので、ここで話すリリース説明会は、そのことを指す。リリースにおいて大事なことは、全てのドキュメントをまとめること。システムをリリースする際には、単にコードだけではなく、開発全過程（かてい）で作り上げたドキュメントも整理または更新して、纏めてお客さんに渡すことが必要である。
登場人物：
石田―　PM。鈴木―　PL。山田、田中、前田―PG。
会話：
石田：こんにちは。
最近、システムが予定通り出来上がっていますので、来週には一回目のリリースをすることになります。今日は、皆を集めて、ユーザーへのリリース説明会を準備することについて相談します。
鈴木：まずは、今回リリースしようとするシステムの機能は、リリースプランにより説明しましたが、今回リリースする実際の内容には再び何が含まれているかを明確にする必要があります。
リリースノート、WARファイル、DB設計書、ソースコード、テストリポートなどがあります。
石田：その中身を皆さんに詳しく説明してもらえませんか？
鈴木：はい。
リリースノートは今回リリースする内容の纏めです。まずは、リリース番号、リリース日付、またリリース責任者などを明確にかかなければなりません。
そのあと必要なのは、今回リリースしようとする機能のリスト、または、前回のリリースと比べて機能の変化を記述することにします。具体的にいうと、新規追加した機能、改修した機能、削除した機能、およびそれぞれ関連したモジュールあるいはクラスの変化を記述すること。
前田：データベースの変更も書くのでしょうか？
鈴木：そうです。データベースの変更を記述することも必要です。すなわち、今回リリースしようとするシステムのデータベースが、前回リリースと比べてデータベースにはどんな変化が起こったかを記述しなければなりません。
具体的にいうと、新規追加したデータベースまたテーブル、またビューあるいはストアードプロシージャ、それと、改修したもの、削除したもの、およびそれぞれに関連したシステムのモジュールやクラスの変化も記述すること。
前田：テストの結果も？
鈴木：そうです。テストの結果もリリースノートに入れたほうがいいと思います。
内容としては、今回テストの状況や増えるか減るかの傾向なども説明したほうがいいと思います。これで品質管理をちゃんと行っているかどうかを説明できます。
石田：リリースノードはわかりますが、お客さんに送る資料はどうなるでしょうか？
鈴木：リリースノートそのものはただのまとめですから、実際のリリース資料は以下のようになると思います。
まずは、ソースコードまたはシステムのバイナリコード、それと、データベース、そのスキーマとサンプルデータ。また、分析設計資料も必要です。これは、ここまで書いたユースケースや、画面設計と帳票設計、クラス図やシーケンス図などを考えています。
最後はテストリポート、バグリポート、と仕様変更連絡票があります。
最後の最後ですが、ユーザーから要求された資料、例えばお客さんとのミーティングの議事録の一部なども必要だと思います。これらの資料はそれぞれの担当者に準備してもらいます。全ての資料は、会社のドキュメント規約により、改修してもらって、ちゃんとした形で出さないといけません。
石田：説明会では、これからの継続開発またメンテナンスに関して議論することがでてくると思いますから、その点についてはどう考えているのでしょうか？
鈴木：そうですね。
われわれの開発手法は反復型RUPあるいはスパイラルになっていますので、今回のリリースはそのスパイラルの一環として位置づけています。そのため、今後の作業に対して、ここまで議論したいろいろな成果物に関して、次回のリリース時に、どんな成果物が必要か、どこまで必要か、また次回リリースするときに期待されるものなどに関しては、われわれもいま検討しています。それと合わせて、今回の開発成果をみて、これまでのリリースプランを新たに更新することもお客さんと相談する必要があります。
石田：それでしたら、なんとか安心できるという感じですね。ところで、来週、お客さんのところへ、だれが行く予定でしょうか？
鈴木：来週は、とりあえず山田君と私で、一緒にいくつもりですが、よろしいでしょうか？
石田：それはいいと思います。お二人で準備してください。
それと、リリースノートができましたら、行く前に、私のところにも一部送ってください。
鈴木：わかりました。
石田：皆さん、ここまでがんばってもらって、どうもありがとうございました。それでは、今日のミーティングはここまでです。皆さんお疲れ様でした。

15.フレームワーク １６．コーディング標準

15.フレームワーク
会話の背景：
コーディングする前に、開発チーム全員にフレームワークとコーディング標準のことを話し、統一的なアプローチを全員に意識させることが必要である。
フレームワークとは、開発環境のフレームワークと実行システムのフレームワークの二つがある。本節ではMVCのStrutsまたORMのHibernateという二つの開発フレームワーク、それとJ2EEの実行システムのマルチレイヤーについて触れる。
登場人物：
近藤―　SA
鈴木―　PL
山田、田中―PG
会話：
鈴木：こんにちは。
いよいよコーディングに入ります。いつものように、コーディングと開発したシステムの質をあげるため、また生産性を高めるため、フレームワークを使います。今日は、このフレームワークの使い方および注意点に関して、チーム全員に認識してもらいたいと思います。
それでは、近藤さんに説明していただけます。近藤さん、お願いします。
近藤：そうですね。今回の開発ではわれわれは開発環境としてEclipseを使って、その上にMVCのStrutsフレームワーク、ORMのHibernateフレームワークを使います。また、開発されたシステムには、J2EEのマルチレイヤーアーキテクチャーを持つように設計していますので。その辺皆に議論をしてもらい、統一したアプローチで開発を行いたいですから、何か質問があるでしょうか？
田中：これまで、われわれはJSP/servlet/Beanで構成したシステムをいくつか開発しましたが、今回MVCのStrutsフレームワークと比べて、どのように違うでしょうか？
近藤：それはいい質問ですね。実はStrutsフレームワークでも、基本的にはJSP/Servlet/Beanによりシステムを開発するわけです。ただし、考えてみたら、ここまでの開発では、例えば、JSPからデータベースのアクセス、またJSPにもビジネスロジックを含んだことがたびたびあります。特に、JSP、Servelet、Bean各自の責任をはっきり強制的に分担させていませんから。
今回StrutsはActionという概念を導入し、servletクラスは直接書かずに、ビジネスの流れはActionで書くことにします。これで、JSPは画面ロジック、Actionはビジネスフロー、BeanはビジネスロジックというようにMVCのデザインパターンを強制的に実施させるため、一つのシステムを三つの側面に分割できると思います。
田中：なるほど。これは、例のMVCすなわちモデル、ビュー、コントローラーですね。
近藤：その通りです。それにより、今回の開発では、画面周りあるいは振る舞いのコーディングはほとんどJSPとActionを書きますが、データアクセスはBeanあるいはドメインクラスを書きます。
山田：ドメインクラスとは、ビジネスロジックもあり、データベースのアクセスもあり、ちょっと複雑みたいですね。
近藤：そうですね。ですから、今回われわれはORMのフレームワークHibernateを導入します。
山田：ORMでもHibernateでも初めて聞いたので、説明してもらえませんか？
近藤：もちろんです。
ORMとはObject　Relational Mappingの省略で、名前のとおり、これはオブジェクトとリレーションナルのデータベースとのマッピングです。コーディングから見ると、ただのJDBCのラッパーに過ぎないとも言えます。
今回われわれが使おうとするHibernateツールはデータベースとオブジェクトの間をXMLにより、緊密に繋ぎますから、コーディングの立場から見ると、今度はビジネスロジックを書く時には、とにかくオブジェクトの世界でコーディングすればいい、データベースのスキーマにはあまり気にしなくてもいいです。
山田：それはいいですね。そうすると、テーブルからオブジェクトへのマッピングのコーディングを誰かにかいてもらうのでしょうか？
近藤：そのマッピングはHibernateがやってくれて、われわれはXMLだけを書けばいいと思います。それと、最近いろいろなツールが出てきますから、それらのツールを使えば、永続的なドメインクラスを自動生成したり、またデータベースが変更されるときにも連動できます。
山田：これは大変便利ですね。それならば、われわれのビジネスロジックを書く人は何を書くわけでしょう？
近藤：そうですね。一般論としては、この永続的なドメインクラスには、画面クラスや、コントローラークラスなどが直接アクセスしてはいけません。それで、ビジネスオブジェクトのクラスが登場します。実際的には、おそらくコントローラークラスと永続的なドメインクラス間にはビジネスロジックを含んだビジネスオブジェクトのクラスがあると思いますが、画面クラスと永続的なドメインクラスの間にもそれらを繋ぐためのビューオブジェクトのクラスがあると思います。
それこそ、できあがるシステムはJ2EEのマルチレイヤーのアーキテクチャーを持ちます。すなわち、プレゼンテーション層、ビジネスロジック層、データアクセス層になります。
山田：わかりました。そうしたら、早速書きましょう。
鈴木：そうですね。先ほど近藤さんが説明したフレームワークが二つあります。StrutsとHibernateです。皆さんにこれらのフレームワークを上手に使ってもらうため、今回のプロジェクトでは、わざわざもう一つ薄いレイヤーを用意しておきます。すなわち、StrutsとHibernateに対するスープークラス：kaiwaJSP,KaiwaAction,KaiwaActionForm,KaiwaViewClass,KaiwaBusinessClassなどを書いておきますから、皆のコーディングはこれらのスーパークラスから出発すればよいのです。
近藤：それと、各スーパークラスの使い方に関しても、例題のクラスを用意していますので、皆さん参考にしてください。
皆：どうもありがとうございます。
鈴木：それでは、今日のミーティングはここまでです。

１６．コーディング標準
会話の背景：
前回はフレームワークについて述べたが、それとともに今回はコーディング標準に関して述べる。コーディング標準は各ベンダーが出している。例えばサンマイクロシステム社が提唱したJavaのコーディング標準などがある。また国際的な標準もいろいろある。しかし、それらの標準のほとんどは全晩的に論じているので、初心者には大変だし、レビューも大変だ。それで、各社は大抵自分の都合で、各自のガイドラインを持ち、要点だけを強調することが多い。
登場人物：
鈴木―　PL
田中、山田、前田―　PG
会話：
鈴木：おはようございます。
前回はフレームワークの話をしましたが、現在はコーディングに入ったところです。今回は新人に入ってもらうし、コーディング標準のことをもう一同繰り返す必要があるのではないかと思いますから、今日はこの辺りについて意見交換しながら話しましょう。
前田：新人の前田です。よろしくお願いします。
コーディング標準にかんしては、学校ではサンマイクロシステム社のjavaコーディング標準を勉強しました。しかし、実際的なコーディングはしていないため、いろいろと教えてください。
鈴木：それはよかったです。うちの会社もサンのJavaコーディング標準をベースにして、コーディングのガイドラインを作りました。今は会社の内部ウェブサイトに置いていますので、皆さんぜひこのガイドラインに従ってコーディングしてください。山田君、田中君、自分の経験をはなしてもらえます？
山田：そうですね。私も経験不足ですが、この二、三年でJavano仕事をやって、いくつか覚えただけです。
一番印象深いのは確か命名規則です。チームワークなので、勝手に名前を付けてはいけないことは勉強しました。まずは、パッケージ名とファイル名ですね。これは会社のるーるがあります。たとえば、すべてのプロジェクトのパッケージは必ずcom,clientcomanpy-name.project-nameのようになっているとか。
その後は、クラス名とメソッド名です。これまではいろいろな言語を勉強したので、いくつかの命名方法を混在していました。いまのガイドラインによると、Javaの場合は、いくつかの名詞や動詞の綴り（つづり）だけでもいいです。ただし、クラス名だと必ず大文字で始まり、属性とメソッド名葉必ず小文字ではじめていくことが必須です。例えば、クラス名はKaiwaClassで、メソッド名はnihonKaiwaMethodのようになります。それと、定数名の場合はキャピタルとアンダーラインで綴ることしか許しません。
前田：命名するときに、日本語を使ってはいけませんか？
鈴木：そうです、日本語を使ってはいけません。全てのコーディング命名規則としては、英数字だけが許されています。その理由は、コンパイルした後に実行システムへ行こうしたり、また別のツールと結合したりするときに、２バイトのコードが入ると予想外のエラーが発生する恐れがありますから。
田中：私が一番経験したのはコメントでした。
最初コーディングするときにはコメントを書く習慣はなかったのですが、それではだめだとチームリーダーから言われました。クラスのコメントにはこのクラスの目的あるいは振る舞いの明確な説明を書きます。その後、やはりコーディング日付、作者、バージョンなどを書きます。
メソッドのコメントには目的、引数、リターン値、例外などを書く必要があります。最近はStrutsを使うときに、ANTでconfigファイルを自動的更新するため、各Actionクラスに特別な情報をコメントとして書くことが必要になりました。これはケースバイケースですが、それでも守らないといけないですね。
鈴木：実はコーディングではJavaでも、.NETでも、原則的にあまり変わらないと思います。すなわち、コーディングがわかりやすく、他人でも読めること。
コーディングのスタイルでも言えますが、原則的にいうと、一つのクラスは20から30ぐらいのメソッドで、一つのメソッドには30行以下などのルールがあります。またコードの行はひとまとまりのパラグラフとなるような4，5行を連続させ、その間には空行を一行いれて、読むときは日本語や中国語の詩のように読めると本当にうれしいですね。
前田：そですか。なかなか面白いですね。
鈴木：もう一つは、コードはパブリック（public)とプライベートインターフェースをはっきり分けないといけない。ここまでのコードを読むと、大部分のコードはほとんどパブリックなインターフェースしかなかったようですが、それではいけませんよ。
やはり、いくらわかりやすくでも、よそと関係ないコードは見せてはいけないので、それらのコードはプライベートなインターフェースにしてください。言い換えると、いいコーディングとは、パブリックなインターフェースをできるだけ少なくなるように書かないといけません。
田中：それと、コードを”掃除”することも大事だと思います。
まず、コードを綺麗にすることです。コードなかの空白、空行、タブ、それとif-then文やwhile文の括弧などをガイドラインで指定したように書かないといけません。
リリースする前に、あるいは各段階では、適当に自分のコードをチェックして、もう要らないコードをよそにだしてしまうことはよくありませんから、自分で掃除しなければなりません。コードはわれわれの製品なので、いつも必要なコードだけを綺麗に出荷することを大事に心かける必要があります。
鈴木：最後なんですが、単体テストはもちろんのことですが、単体テストしなくても、本人が書いたコードの自己テストが必要です。たとえばクラスごとに、パブリックなインターフェースに対するテストメソッドをつけることを習慣にすれば有用だと思います。それでは、今日のミーティングはここまでですが、コーディングに関する議論は続けてください。

13.データベース設計 １４．テストを計画する

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倍に延長しようかと考えます。機能テストと統合テストは、コーディングをしながらやりますので、できれば、少なくとも一人の専業テスターを用意します。パフォーマンステストは大抵コーディングが終わる時点なので、その時点になると、プログラマーから一人か二人をまた追加して、やってもらいたいですけど。
鈴木：それならばいいと思います。
石田：それでは、今日のテスト計画に関するミーティングは終了します。皆さん、お願いします。
皆：よろしくお願いします。

11．シーケンス図を書く １２．状態図を書く

11．シーケンス図を書く
会話の背景：
システムモデリングには、静的なモデリングと動的なモデリングがある。静的なモデリングがある。静的なモデリングがクラスに重点を置くというなら、動的なモデリングはオブジェクトに注目している。今回と次回は動的あるいはダイナミック的なモデリングについて話す。動的なモデリングはいくつかあるが、よく使われているのは、シーケンス図と状態図である。どちらでも静的なクラスに基づいて設計する。シーケンス図の特徴は、オブジェクト間（かん）の相互動作を時系列で表現することである。
登場人物：
近藤―　SA
鈴木―　PL
山田、田中―　PG
会話：
鈴木：こんばんは。
先々週からはクラス図を書いてきました。これは静的なモデリングと言われます。今週からは動的なモデリングをします。作業としては、シーケンス図と状態図を書く予定です。今日は、まず、シーケンス図に関して、近藤さんに説明してもらいましょう。近藤さん、お願いします。
近藤：そうですね。ここまで書いてもらったクラス図では、主にオブジェクトのテンプレートとなるクラスの名前、属性、および操作を定義し、その上各クラスの関係付けも記述しておきます。それに対して、システムが実行するときに、システムの制御の流れがどうなるか？各オブジェクトがどう動くか？お互いにどう交信（こうしん）しながら機能を果たすか？また各オブジェクトが自分のライフサイクルでどう変化するか？などを記述することを動的なモデリングと言います。
田中：すみませんけど、動的なモデリングって、具体的に言うと、いくつかの種類がありますか？それぞれの特徴および適応性はどうでしょうか？
近藤：そうですね。いろいろありますが、よく使われてるのは、コラボレーション図（collaboration diagram)、シーケンス図（sequence diagram)、状態図（state diagram）、それとアクティビティ図（activity diagram)があります。
コラボレーション図は各オブジェクトがイベントにより交信することを重視したもので、時間には関係なさそうな振る舞いを表現するにはいいと思います。
それに対して、シーケンス図は関係オブジェクト間の時間序列（じょれつ）により交信することを表現するので、時系列にかかわる機能には表現しやすいです。
田中：もしかしたら、アクティビティ図と状態図もオブジェクト間の振る舞いを表現するのでしょうか。
近藤：それらはちょっと違いがあります。
アクティビティ図はシステムの制御の流れは表示しやすいと思います。むかのフローチャートやデータフロー図から変身してきたと思います。ここでは流れの主体はオブジェクトになっています。状態図はオブジェクト間の関係ではなく、ある特定のオブジェクトに対して、そのライフサイクルの中で状態の変化を表現します。もちろん、その状態の変化とともに、イベントが発生しますから、それも一緒に記述します。
田中：なるほど。大体わかりました。われわれも今回の四種類の図を書かなければなりませんか？
鈴木：本来はそうすべきですが、しかしプロジェクトによりお客様の要求次第でまちまちですから。今回はとにかくシーケンス図と状態図だけを書けばいいことになりました。
田中：そうですか。そうしたら、シーケンス図に関して今回の作業ではどう書けばいいでしょうか。
近藤：この前も言いましたが、シーケンス図にはハイレベルとローレベルの書き方があります。今回の開発はこのシステムがそんなに大きくないので、ローレベルの書き方を薦めたいです。
田中：ローレベルの書き方って、どんな意味でしょうか？
近藤：ローレベルの書き方とは、コーディングと緊密に関係した方法です。具体的にいうと、ここまで設計したクラスとこれから書こうとするJSPやJavaの名称や操作などを直接使いながら書きます。たとえば、お客さんが見積記入という振る舞いを記述して見ると、NewQuotationJSP,NewQuotationAction,Quotation,Approvalなどのクラスがある。その場合、これらのクラスのオブジェクトあいだの交信を時系列で書けばいいと思います。具体的には、サンプルも書いておきますから、参考にしてください。
田中：どうもありがとうございます。
山田：それと、シーケンス図に対して何か特徴や注意点などがあるでしょうか？
近藤：そうですね。まずは、今われわれはローレベルで書いていますので、大抵（たいてい）一つのセッションには一つのシーケンス図があります。そうすると、シーケンス図を読むと、コーディングがすぐできるような状態になります。逆にいうと、コーディングがあれば、シーケンス図により、検証することもできます。
山田：それは大変助かります。
近藤：それと、シーケンス図には、細かくいうと、オブジェクト間でメッセージ通信するときに、条件をつけることがよくありますから、条件を書いたほうがいいとおもいます。
二番目は、関係したオブジェクトが流れのあいだに生成されたり（new,create)、消滅されたり(destroy,delete)、自己交信する（self)こともよくありますので、UMLの記号を正しく使ってちゃんと表示してほしいです。
山田：ところで、シーケンス図が、並列プロセスも表現できるでしょうか？
近藤：もちろんです。シーケンス図で並列プロセスを表示するため、頭が半分しかない矢印を使って非同期メッセージを送信するように表現できます。
一般的にいうと、シーケンス図では、あるオブジェクトが相手のオブジェクトに送信し、相手のオブジェクトが処理を終えた後、次の操作へ進む。これにより、時系列を守ります。図を書くときには、こんな送信は普通の矢印を使います。
しかし、並列プロセスあるいは非同期の場合は、非同期メッセージを送信した後、呼び出し側をブロックしませんので、自身の処理を継続して実行できます。というのは受信側オブジェクトの処理完了を待たずに、すぐ次の動作を続けます。
山田：わかりました。
鈴木：それでは、具体的にはまだいろいろがあると思いますが、書きながらまた議論してきただければ勉強になると思います。今日のミーティングはここまで終わらせてもらいます。皆明日から早速書いてもらいましょう。
もう遅くなりましたので、近藤さん、皆さん、お疲れ様でした。
皆：お疲れ様。

１２．状態図を書く
会話の背景：
前回はシーケンス図の書き方などを話した。動的なモデリングをするため、シーケンス図とともに、多くの場合、状態図も書く。
シーケンス図にはほとんどのクラスが登場するが、状態図は一部のクラスの処理が状態に依存して複雑な処理になる場合のみ、必要なるいは有効である。それ以外の場合は必ずしも書く必要はない。
登場人物：
近藤―　システムアーキテクト
鈴木―　PL
山田、田中―　PG
会話：
鈴木：おはようございます。
このところ、シーケンス図を書くたびに、その中の一部のオブジェクトに対して状態変化に関する議論がたびたび出てきました。今日は時間を取って、これらの状態変化について、UMLの状態図をどうやって取り込むかを議論してほしいです。
山田：そうですね。
われわれは先日、問い合わせ記入、商社への見積、顧客注文、販売店への注文、納品管理などのシーケンス図を書きました。ただし、書いているうちに、いくつかのシーケンス図間（かん）の関連情報をどう反映するか、迷っていました。
例えば、顧客注文を照会するときには、ここまでの見積状況や、販売店からの返事などをひきださなければなりませんから、なにかよい方法がないかなと感じました。
近藤：なるほど。それこそ、確かにわれわれはこの車両販売管理システム中の取引というオブジェクトに注目しなければなりません。ここで、取引とは、最初の顧客の問い合わせの記録だけではなく、見積や注文、納品、最後の会計まで、状態が変わっていくように表現しなければなりません。これを状態図で分析設計すれば、問題が解決できると思います。
山田：そうですか。ということは、取引オブジェクトに、問い合わせ中、見積中、販売店注文中、納品済み、請求済みなどの状態を取り込めば、いいわけでしょうか？
近藤：どうです。
一つの取引は、最初の問い合わせから、最後の納品また会計までの状態遷移により、販売のビジネスを進めていくことを記述できます。
また、各状態に対して、状態遷移の条件やイベントがあり、特定の条件を満たせば、または、あるイベント発生したら、状態Aから状態Bへ遷移します。また状態遷移の後はほとんどの場合アクションが発生します。
田中：すみませんけど、状態遷移の条件と状態遷移あとのアクションと言われましたが、もつちょっと詳しく説明していただけるでしょうか？
近藤：はい。先の取引の例をとってみてみましょう。
ある特定の取引に対し、顧客が注文を確認したあとに、システムが特定の条件を確認したうえで販売店へ正式注文します。そうすると、取引は注文中という状態を持っています。この状態を変更すると、こちらのシステムが販売店に注文することになります。
その場合は、この状態遷移の条件としては、確かに顧客の確認だけではなく、たとえば代金の30％がこのシステムにはいらないといけないことは、状態遷移の条件ともかんがえられます。
また、一旦この頭金の条件を満たすと、システムとしては、直ちに特定の販売店に注文するアクションが発生しなければなりません。それは、今回顧客注文の状態遷移のアクションともいえますね。
田中：それを聞いたら、わかってくるようですが、取引にはいくつかの状態があります。しかし、もし細かく考えると、注文という状態の中にも入れ子の状態があるようですけど。
近藤：その通りです。オブジェクトの状態は階層化することができますから、言い換えると、ある状態のなかで、また入れ子状態を持つことがよく発生します。これらの階層化された状態をUMLで記述することもできます。
入れ子状態だけではなく、並列状態もあります。ようするに、状態とは、単独的なものだけではなく、並列した状態を同時に処理することもたびたび発生します。そのときは、二つの状態の「And」また「Or」の論理演算により、次の状態へ遷移するかどうかが決まるわけです。
例えば、ローンで自動車を買うときに、顧客からの頭金により注文状態と、信販会社からの審査結果状態は両方がOKだったら、次の販売店注文状態へ行きます（これは「AND]論理）。ところが、その二つ状態のいずれも成り立たないと、結局、拒否される状態へ遷移します（これは「OR」論理）。
山田:それはわかりやすい例ですね。
ところで、今回の車両販売管理システムでは、どんなオブジェクトの状態を記述する必要があるでしょうか？
鈴木：一般的にいうと、一つのシステムには状態を持つオブジェクトはほんの一部しかないので、例えば、われわれの今回のシステムにはおそらく取引オブジェクトと注文オブジェクトには状態があると思います。
具体的には、皆に考えてもらいます。大抵状態が必要とするオブジェクトは特定の属性をもち、これたの属性の変化範囲は有限ですが、さらに離散的な値に限定されていることが多いです。
近藤：そうですね。
要求定義により、一部オブジェクトが持っている属性が連続値になっているが、値として状態を持つこともあります。そのときには、連続値を区間で区切った仮想的な離散地へ変換することが必要だと思います。
山田：そうですか。よく説明していただき、どうもありがとうございました。
鈴木：それなら、そのあとは実践ですね。皆さんにシステムの要求を考察してもらい、状態のあるオブジェクトを洗い出して、その状態を記述してもらいます。皆さん、よろしくお願いします。
皆：それでは、失礼します。

９．帳票設計と作成 １０．クラス図を書く

９．帳票設計と作成
会話の背景：
帳票の設計と作成は、多くのソフトウェア工学の教科書ではあまりろんじられていない。現実では、特に日本の開発現場では、帳票の設計と作成に関する工数が大きく影響し、苦労することも多い。
帳票の設計と作成の重点は現場で使えるものとして、その実用性と便利さにある。そのため、現在すでに使っている手書き帳票や、システムの画面などをよく調べ、その上で設計した帳票サンプルを使って、早めにユーザーと調整することが大事である。
登場人物：
鈴木―　ＰＬ
山田、田中―　ＰＧ
会話：
鈴木：おはようございます。
前回の画面設計の検討に続いて、今日のミーティングでは帳票設計と作成の方（ほう）も本格的な検討に入りたいと思います。
山田：われわれが今回作る販売システムは、この前聞いた話では、これから管理を電子化し、”ペーパーレス”が目的と理解していますが、紙ベースの帳票はまだ必要でしょうか？
鈴木：そうですね。最近のメディアでは、”ペーパレス”とよく言われていますが、実はいくら電子化しても、実際には紙の使用量が増えていることが報告されています。少なくても、われわれのこのシステムでは、現場で今、使っている帳票のほとんどを出力することが必要になりまる。
具体的にいうと、領収書、請求書、注文書、納品書などはフォーマット通りにきちんときれいに出力できないといけないでしょう。このような帳票設計と作成に関する作業が全体の工数には大きく影響しますし、苦労することも多いと思います。
山田：そうですか。それでしたら、われわれがどうしたらいいでしょうか？
鈴木：まずは、皆にユーザーの現場で今使われている帳票のサンプルを集めるからはじめてもらいたいです。業務上（じょう）では、紙ベースの領収書、請求書、注文書、納品書などがあると思います。また、管理の面から見ると、売り上げの集計や販売実績の一覧などの管理系の帳票も紙への出力が必要なので、それらのサンプルもほしいですね。
山田：私が思うのは、サンプルを集めたら、一覧を作成し、重要度を付けます。その上で、各種類の帳票に関して、今回はそのまま出力するか？いらなくなるか？修正があるか？などを記述した上、ユーザーともう一度打ち合わせて進めて行くというのは、どうでしょうか？
鈴木：そうです。その通りですね。
それと、更に、各種類の帳票がどこのユースケースとつながり、またどこで出力するかなども記述しなければなりません。
田中：画面上での照会などの結果も出力して、帳票の一部として取り扱いますか？
鈴木：そうです。ただし、画面上で表現すると、画面おサイズの問題があり、またスクロールのこともあり、そのまま出力するとまずいかもしれません。やはり各出力に必要な画面に対して、ちゃんと帳票を設計しておいて、特別な工夫が必要だと思います。
田中：わかりました。
それと、出力のフォーマットはなんでしょうか？
鈴木：今回のお客さんがオープンソースソフトウェアに興味があり、ＰＤＦの出力であればいいといわれましたので、基本的にはＰＤＦで出力します。
ただし、一部の出力はExcelになるケースもあると聞きましたので、これは注意を払って、慎重に調査してから対応しなければなりません。この件に関しては山田君にお願いしたいのですけど、どうでしょうか？
山田：わかりました。調査します。ところで、出力のためのデータに関しては、今データベース設計もできていないため、どうすればいいでしょうか？
鈴木：そうですね。帳票設計と作成は実は長期的な作業です。まずは、われわれが必要な帳票などを設計しておきましょう。この設計はこれからのデータベース設計の参考にもなりますから。本番の帳票作成は、コーディングの一部として作業します。勿論その時も帳票設計の微調整があると思います。
山田：そうなると、時間がかかりますね。帳票設計や作成にかんするツールはありますか？
鈴木：帳票設計や作成に関するツールがたくさんはないですが、調べればかならずあると思います。たとえば、Jreportなど。とくにPDF出力に関しては、いくつか見たことの記憶があるので、田中君、調べてもらえます？
田中：はい、調べてみます。
鈴木：帳票設計や作成には、ツールがあっても工数がかかることに注意しなければなりません。大抵帳票設計がいくら綺麗にできても、実際的なデータを入れて出力しないと結果はわかりません。効果がぜんぜん違うことがしばしばありますから。そのため、やはり空の帳票だけでテストしてはいけません。必ず実際の、あるいは、現場で使っているデータにちがい数字によりテストすることが必要です。
そうしたら、山田君にはユーザーの帳票を集めて、さらにEXCELフォーマットの出力可能性についても調べてもらいます。田中君は帳票設計と作成ツール、まずはPDFに関するツールを調査してください。よろしくお願いします。それらができたら、われわれは再びミーティングを開いて、帳票の詳細設計と作成作業に関して議論しましょう。それでは、今日の会議はここまでです。みなさん、お疲れ様でした。
皆：お疲れ様でした。

１０．クラス図を書く
会話の背景：
ここにきて、やっと詳細設計に入る。
オブジェクト指向技術をベースにした開発する場合は、クラス図は詳細設計のベースとして位置づけられる。クラス図では、モデリング標準のUMLに従って、クラスおよびそれらの関係を表現し、各クラスの主な属性や操作などを記述する。
登場人物：
近藤―SA
鈴木―PL
山田、田中―PG
会話：
鈴木：こんにちは。今週から詳細設計に入ります。予定としてはクラス図、シーケンス図、状態図、それとデータベース設計を中心に作業してほしいです。今日は近藤さんにクラス図の作成方法などを説明してもらいます。それでは、近藤さん、よろしくお願いします。
近藤：承知しました。ここ数年前から、オブジェクト指向やUMLなどはすでに分析設計の常識になってきました。説明するため、まずUMLについてちょっと触れたいです。UMLとはUnified　Modeling Languageの略称で、言い換えると統一モデリング言語です。
山田：そすると、UMLはすでに国際標準になっているわけですか？
近藤：そう言っても間違えないと思います。20世紀末の90年代にはたくさんのモデリング提案が出まして、その後Booch,RumbaughとJacobsonの三人がその揃って、統合的なUMLを提案が出まして、その後Booch、RumbaughとJacobsonの三人が揃って、統合的なUMLを提案した。この提案はOMGが1997に発表しました。いま、UMLは単に設計モデリングだけではなく、プロセスの定義言語、テストのフレームワークなどさまざまな分野へ展開しています。
田中：私もこの前ひとつのUMLコースを勉強しましたが、UMLとは、単に設計図を書く記号にすぎないと感じましたけど。
近藤：UMLはもちろん設計図を書く記号ですが、しかし設計の意図を正しく、正確に伝えるため、やはりこの記号の後ろにあるオブジェクト指向技術をマスタ－しなければなりません。
田中：これはクラスとオブジェクトのことを指しますか？
近藤：そうです。
本質的なのはオブジェクト指向の考え方です。オブジェクトというのは、現実的なものをコンピューター世界へ反映させた表現です。例えば、現実には車両があり、われわれのシステムではCarというオブジェクトで表現します。また、車両販売管理の現場では見積があり、システムではそれに対応したQuotationオブジェクトが存在します。
山田：それならば、このQuotationオブジェクトは現場での見積もり情報の集まりでしょうか？
近藤：そうともいえますが、それは、オブジェクトのある一つの側面です。オブジェクトとはデータを持つだけではなく、振る舞いも持ちます。データと振る舞いを統合することはオブジェクトの特徴ですね。
山田：なるほど。今回のクラス図はデータと振る舞いのどちらを表現するのでしょうか？
近藤：UMLでモデリングするには大きくわけると二種類のモデリングがあります。すなわち、静的なあるいはStaticなモデリングと動的なあるいはDynamicなモデリングがあります。今日話したいクラス図は静的なモデリングの一種です。クラス図は主にクラスの名前、属性、および操作を定義し、そのクラス間の関係付けを記述します。
田中：クラスの関係は複雑でしょうか？
近藤：そうでもありません。クラスの関係は大きく分類すると、継承関係、集約関係、それと関連関係という三種類があると思います。
継承関係とは基本的には同じタイプのものに対して、汎化性を抽出し、スーパークラスに定義します。特殊性はサブクラスになり、スーパークラスの持っている属性と操作を継承しながら、特別な属性や操作を記述します。
田中：それで、集約関係と関連関係の区別はなんでしょうか？
近藤：まず、関連関係とは、単にオブジェクトの関係をクラスレベルで表現したのもです。例えば、PersonというクラスとCarというクラスとの間には、「運転する」という関係があります。集約関係は関連関係の特殊なものともいえます。詳しく言うと、部品を表すクラスと、それを用（もち）いて組み立てられるクラスとの関係です。集約関係の特徴は、部品側オブジェクトが組み立て側オブジェクトに依存することです。
鈴木：例をあげると、自動車（car）というクラスがあって、一般的には自動車ですが、日産社製自動車（NissanCar)とToyota社製自動車はそれぞれ自動車（Car)継承関係を持ちます。自動車クラスが見積クラスや注文クラスとは関係を持っています。それと、自動車とタイヤクラスは関連関係ともいえますが、依存関係がありそうなので、集約関係を持つことも考えいられます。このような考えはよろしいでしょうか？
近藤：なかなかいい例ですね。
分析の初期には、一つは継承関係の定義を慎重に使ったほうがいいと思います。なんでもかんでも継承関係を付けることはいけませんね。また深い継承関係もさけてくささい。二つ目は関連関係が集約関係かなどを悩む必要はありません。もしはっきりわからなければ、とりあえず関連関係でもいいですから。属性や操作を定義しながらわかってくると思います。
最後に言いたいことは、クラス図を書くときには、システムが大きすぎると一枚の紙で書き切れないこともよくありますから、クラスをグルーピングすることが必要です。
われわれが今回開発しようとする車両販売管理システムの場合は、いまのところのユースケースやコンセプト図を読むと、大体60個以上のクラスがあると思います。そうすると、おそらく三つまたは四つぐらいのグループに分割すればいいと思います。
鈴木：そうですね。確かにグルーピングすることが必要ですね。わたしのイメージでは、例えば車両や部品などのクラスは品物のグループで、お客さん、メーカー、商社、営業マンなどは組織のグループになると思います。最後は、請求書、納品書、注文書などのクラスはまた一つのドキュメントグループになるかもしれません。
田中：わかりました。
鈴木：それでは、今日のミーティングはここまでです。近藤さん、どうもありがとうございました。皆さん、ありがとうございました。
皆：ありがとうございました。

７．用語辞書 ８．画面設計

７．用語辞書
会話の背景：
システム分析段階では、用語辞書の作成を大事にしなければならない。
ユースケースやコンセプト図または詳細設計時のクラス図などもこの辞書で定義される用語に基づいて作成する必要がある。
用語辞書のライフサイクルはプロジェクトまたはシステムと同じであり、用語辞書をシステム分析からメンテナンスまで、ずっと維持する必要がある。また、すべてのプロジェクト参加者は、必要に応じて用語辞書を参照しなければならない。そうすることにより、コミュニケーション上（じょう）で起こる相互理解の不足や誤解を回避（かいひ）することができる。
登場人物：
近藤―　システムアーキテクト
鈴木―　ＰＬ
山田、田中―ＰＧ
会話：
鈴木：こんばんは。今日の昼には時間がなかったため、午後のミーティングはいまからしますが、よろしくお願いします。
そろそろユースケースの作業が終わり、前回議論していたコンテキスト図やコンセプト図なども作成しています。今日は近藤さんに用語辞書のことを皆さんに説明してもらいたいと思います。
田中：われわれも辞書を作るのですか？
近藤：そうです。ここでの用語辞書と言うのは、われわれがこのシステムを開発するために必要な辞書のことです。
田中：それにはなにを載せるのでしょうか？
近藤：基本的には、われわれがいまから使う言葉、名詞や動詞でも、用語辞書に入れてもらいます。
田中：その辞書の目的は？
近藤：そうですね。今、われわれは分析をしていますが、これから詳細設計に入り、その後はコーディングをします。そのときクラスを定義したり、メソッドを定義したりしますから、用語をちゃんと定義しないと、今話していることが、これから開発するシステムと整合性が取れなくなる恐れもあると思います。
田中：そうすると、各項目には、どんなものがありますか？
近藤：これははっきりとルールはないですが、われわれの経験だと、ひとつの項目には名前、英語名、意味・記述、連語、用例などが必要と思います。
鈴木：例をあげていただけるでしょうか？
近藤：いいです。
たとえば、見積という項目を例として、以下のようになると思います。
名前：見積
別名：見積もり
英語名：Quotation
意味．記述：お客様が注文する前に、品物の値段や品番などをまず調べる。そのときの問い合わせは見積と定義する。
連語：見積依頼、見積書作成、見積情報の照会など。
用例：お客様が見積を依頼する。
山田：それはわかりやすいですね。これだと開発するときにはみんなで、同じ言葉を使うことができます。
近藤：用語辞書は開発するときに使うだけではなく、メンテナンス時にも使います。こんな辞書がないと、メンテナンスの人は大変ですから。
山田：そうすると、この用語辞書のライフスタイルはプロジェクトまたはシステムとおなじになりますね。
近藤：そうです。
全てのプロジェクト参加者は用語辞書を参照しますから、システム分析からメンテナンスまで、用語辞書をずっと維持する必要があります。
鈴木：それはいいですけど、しかし、だれが責任を持ってこの辞書を作るか、誰が責任を持ってこの辞書を維持いていくかが問題ではないかと思いますけど。
近藤：その通りです。用語辞書に関しては、まず作成また編集の責任者が重要です。というのは、用語はシステムの各側面から出てくるので、できるだけ、みんなから集める必要があります。その集める方法を考えなければなりません。
鈴木：そうですね。用語辞書の配布（はいふ）も問題になると思います。これまでのやり方だと、紙に印刷して開発チームメンバーに配ることはできます。しかし、特に特に分析設計段階では用語辞書もよく変更されますので、いちいち配布すると、紙も無駄だし、皆に混乱を生じる恐れもあります。
近藤：最近、ウエブの方法で用語辞書を作ったり管理したりする方法が普及して来ました。というのは、用語辞書のサイトを立ち上げれば、皆が追加することができます。またどこでもいつでも参照することもできます。いかがでしょうか？
鈴木：それはいいと思います。
山田：最近ＷＩＫＩというものを見ました。あれを使えば、チームメンバーが自由に追加したり、参照したりすることもできます。できれば、適当なＷＩＫＩエンジンを使って、用語自称を作ったらどうでしょうか？
鈴木：それはいい考えかもしれませんね。早速参考にして作ってみましょう。
今日はここまでにしましょう、近藤さん、どうもありがとうございました。皆さん、どうもありがとう。
皆：どうもありがとうございました。

８．画面設計
会話の背景：
詳細設計に入る前に、最後の作業として画面設計と帳票設計がある。
ここでいう画面設計とは画面の衣装設計ではなく、システムとしての完成予想図をユーザーに伝えるために設計のことである。また、ウエブ系のシステムの画面設計は従来のクライアント・サーバー系と相当違いがあるので、十分気をつけなければならない。
登場人物：
石田―　プロジェクトマネージャー
鈴木―　ＰＬ
山田、田中―　ＰＧ
会話：
石田：こんにちは。
今週までに、ユースケースをはじめ、用語辞書までできあがりましたので、いわゆる要求分析段階のドキュメントはほとんどできました。今週からは画面設計に入りたいのですが。
山田：画面設計とは、先日鈴木さんなどが画面のレイアウトなどをやっていたことを時々（ときどき）みましたが、それのことですか？
鈴木：ええ、それは画面設計ともいえますが、少し、違います。私が先週からよその意匠設計専門の方と打ち合わせとしたりして、今回のシステムの全て画面のレイアウトやアイコン、また会社ロゴなどは大体決まりました。
石田さんが言った画面設計とは、おそらくわれわれのシステムの全部の画面作成だと思います。そうでしょう、石田さん？
石田：その通りです。
今日皆を集めて、画面設計をやってもらうことは、われわれのシステムの完成予想図を示すためのものです。もっと具体的に言うと、今回はウエブシステムなので、ＨＴＭＬですべてのデモができる画面を作り出すことです。
山田：ＨＴＭＬなら簡単だとおもいますので、大丈夫だと思います。
鈴木：そんなに簡単とは思わないのですけど。今回皆に作ってもらうＨＴＭＬ画面はシステムの紙芝居のように動かないといけないという要求があります。とういうのは、各画面では、たとえば特定のリンクを押すと、指定した画面へ遷移することが必要です。
田中：それは大変ですね。
鈴木：そうですけど、いわゆる紙芝居のようなものなので、たとえば10行のリストがあり、リストの各行には追加、削除というボタンがあるという場合に、設計したＨＴＭＬ画面中の各行に追加と削除ボタンをつけますが、おそらくただ一行だけ追加ボタンが有効で、また別のある行だけでは削除ボタンを有効にしているかもしれません。全ての行にすべてのボタンを有効にする必要はありません。
田中：なるほど。しかし、それでも工数が必要ですね。
石田：そうですが、やはりやらないといけないと思います。
なぜかとういうと、まずは、われわれここまでユースケースなどをたくさん書きました。これらはユーザーさんのＩＴ部門の方にチェックしていただきますが、普通のエンドユーザーには、それだけだと、ちゃんと理解するのに無理があります。それで、このシステムの完成予想図として、動いているようなものを見せないといけない。エンドユーザーに、開発できたらシステムはこのようなものだ、といいたい訳ですから。
鈴木：これには、相当的な工数がかかりますが、むだとは思いません。われわれは今回の実際的なシステムでは、画面の部分はＪＳＰで書きますので、ＨＴＭＬで書いた画面設計のファイルを徐々にＪＳＰへ作り直していけばいいと思いますから。
今の画面のレイアウトやアイコン、また会社ロゴなどができましたので、サンプルとして皆に配布します。皆がこれをベースにして、各自のユースケースに基づいて作ってもらいたいです。
山田：ユースケースだけだと、画面と機能のつながりが不明なことがよくありますが、どうすればいいでしょうか？
鈴木：これはいい質問です。私の方は一つの機能リストを書きました。このリストでは各画面上でどんな機能がありそうだ、どこへ遷移するなど、大体書きましたので、皆に参考してもらいます。
それと、皆の作業に伴い、私の方がこの機能リストを画面遷移フローへ変換しますから。最後には、私たちの画面設計と私の画面遷移フローと一緒に開発ドキュメントとして納品するつもりです。
山田：わかりました。
ところで、いまのＨＴＭＬで作るウェブの画面設計と以前のクライアントサーバーの画面設計との違いがあるのでしょうか？
鈴木：そうですね。ウェブの画面にはいくつかの特徴があります。まずは、特にビジネスあるいは基幹系のシステムでは、ウェブの画面はなるべく簡単にする必要があります。例えば、大抵（たいてい）一つの画面では一つのテーブルしかなく、一つのテーブルには２，３個のボタンが独立存在するようなものです。旧来のクライアントサーバー系の画面設計のように、一つ画面では複数のテーブルやコンポリストがあって、あちこちの連動することはウェブには相当無理があるそうです。
それと、ウェブじょうではセッションの概念があるので、複雑で長いセッションはあまり好ましくありません。いまの画面設計とあとの実現では、ビジネスのアクションをできるだけ単純で短くしたほうがいいと思います。いくつかのビジネスアクションが連続していて長くなると、ネットワーク上（じょう）でなか発生するのか予想できませんから。
山田：通常のウェブサイトでは皆がフラッシュなどをよく使って、動画的な効果を出していて、感動しますが、われわれも使いますか？
鈴木：それはケースバイケースですね。動画的な効果にはコストがかかると思いますから。今回われわれが開発しようとするシステムはビジネスシステムなので、ビジネスの正確性、操作の簡単さ、システムのパフォーマンスなどが最優先なので、動画的な効果はなくてもいいでしょう、残念ですけど。
山田：そうですか。わかりました。
石田：それでは、皆さん、鈴木さんの書いた機能リストと各自分担したユースケースにより、画面設計の作業に進んでください。きょうのミーティングはここで終わりにします。皆さん、ありがとうございます。
皆：どうもありがとうございます。

５.ユースケースを書く ６．コンテキスト図とコンセプト図

5.ユースケースを書く
会話の背景：
ユーザーの要求を明確に記述するために、ユースケースを書く。
ユースケースはシステムと外部との相互作用を表現するもので、システムの機能仕様であり、あるいは、ユーザーと開発者間の契約とも言える。
なぜなら、これらは、われわれが開発しようとするシステムが、どのようになるかをユーザーに説明するもので、ユーザーとのコミュニケーションの大事な手段ともなる。
また、ユースケースはシステム開発プロセスを駆動する中心的なドキュメントでもある。
登場人物
鈴木ー　ＰＬ
佐藤、田中－　ＰＧ
会話：
鈴木：おはようございます。
これまでに、われわれはユーザーの要求をよく聞き、現場の資料も集めました。これからは、もっと厳密にユーザーの要求を記述しなければなりません。そのために、これからユースケースを書いて、要求を整理しましょう。
佐藤：ユースケースについて聞いたことがありますが、実際に書いたことがまだありませんので、簡単に、紹介してもらえますか？
鈴木：そうですね。ユースケースはわれわれが開発しようとするシステムの機能をユーザーに説明する手段です。ユースケースでは、さらにシステムの境界を定義します。つまり、だれがこのシステムを使い、このシステムがどこまでの機能を持つのかということを定義します。
佐藤：わかりました。でも、どんなドキュメントを書くでしょうか？
鈴木：ユースケースのドキュメントは二つの種類があります。まずはユースケース図です。二番目はユースケース記述です。
佐藤：ユースケース図の記号と要点は、何でしょうか？
鈴木：各々（おのおの）ユースケースは一つの機能または操作を記述するので、基本的には誰が何をするかを記述します。そのため、ユースケース図では基本的にユースケース名（楕円）、アクター（人型）、関係（接続線）を含んでいます。
佐藤：例で説明してもらえるでしょうか？
鈴木：はい。たとえば、車両見積もり作成という機能では、ユースケース名は「車両見積を作成する」で、アクターは営業マンと外部のデータベースで、アクターとユースケース名の間は、連続線で結びます。
田中：すみませんが、営業マンがアクターになることはわかりますが、なぜデータベースもアクターになるでしょうか？
鈴木：そうですね。ユースケースは実現しようとするシステムの立場から記述するので、このシステム以外で、システムと相互作用をする特定の機能を持つもの、または特定の操作を行う別のもの、たとえば外部のシステムやデータベースなどを操作するものならば、すべてはアクターと呼ばれます。
田中：そうですか、わかりました。
それと、もしシステムの機能が複雑で、一つのユースケースでうまく表現できない場合はどうすればいいでしょうか？
鈴木：そんなことはよくあります。そこで、ユースケースの間には包含、拡張の関係があるので、これらの関係を使えば、一つの大きなユースケースをいくつかに分離し、いろいろなユースケース間の関係を表現できると思います。
田中：なるほど。それでは、ユースケース記述の方法を教えていただけますか？
鈴木：はい。ユースケース記述を照会しましょう。
ユースケース記述はユースケース図より正確に定義する手段として、ある機能のイベントフローを記述します。もちろん、このイベントフローはシナリオ図で書くこともできますが、シナリオ図はイベントフローの一つインスタンスだと思えばいいと思います。ユースケース記述はユースケース図より詳しく機能の流れを記述できます。実際には、ユースケース図よりユースケース記述のほうがもっと重要だと思います。ユースケース図は、他人に説明をするなら、また、システム全体を理解するには有効ですが、ユースケース図だけでは、機能の仕様を表すには、十分ではありません。
田中：それは助かります。ユースケース図記述を行うときの要点はなんでしょうか？
鈴木：ユースケース記述に関しては、ＵＭＬ標準の中では統一されていませんが、大抵以下の部分を含んでいると思います。ユースケース名、概要、基本フロー、代替（だいたい）フロー、例外フロー、事前条件、事後条件、などです。
佐藤：概念は大体わかりましたが、ユースケース図でもユースケース記述でも、サンプルをいただけるでしょうか？
鈴木：それは後で、例を挙げましょう。
佐藤：最後ですが、ユースケースに関してどんな参考文献がありますか？
鈴木：そうですね。たとえば、アリスターコーパンさんが書いた「ユースケース実践ガイド―効果的なユースケースの書き方」という本は参考にできると思います。訳本（やくほん）は翔泳社が出版しました。それ以外にもいろいろありますが、サンプルと一緒にリストしておきましょう。
佐藤：どうもありがとうございました。
鈴木：それでは、皆さんには今回車両販売管理システムのユースケースを書いてもらいます。がんばってください。きょうのミーティングはここまでです。

６．コンテキスト図とコンセプト図
会話の背景：
システム分析段階ではユースケースを作成することが中心的な作業であるが、しかしながら、ユースケースだけではうまく表現できない部分も相当ある。たとえば、システムの全体に関する概念や機能、また外部との情報交換など。それに対していろいろな手段がある。ここではコンテキスト図やコンセプト図を紹介する。
登場人物：
近藤―システムアーキテクト
鈴木―　ＰＬ
山田、田中：ＰＧ
会話：
鈴木：こんにちは。
これまでに、皆さんにユースケースを書いてもらいました。大変お疲れ様です。なにか問題があるでしょうか？われわれはどう対処（たいしょ）すればいいか、などを議論してもらいましょう。
山田：そうですね。ユースケースの書き方はなんとかわかってきましたが、具体的なユースケースを書くと、システムの全体に関する概念や機能などが見えなくなる恐れがありますが、それにたいして何かいい方法あるでしょうか？
近藤：はい。まず、よくやっている方法はユースケースリストです。すなわち、一つの画面（図形の方法）また一枚のページ（テキストの方法）で、全てのユースケースのタイトルを番号で関係をつけながら、集めてリストしておきます。
山田：ＯＫ、わかりました。
もう一つは、実際的な現場のユーザーには、データの流れを表現していないユースケース図は、直観的に理解しにくく、データの流れを表すＤＦＤのような設計図のほうがわかりやすいではないでしょうか？
田中：すみませんが、ＤＦＤとは？
鈴木：ＤＦＤはData Flow Diagramの略です。すなわち、データの流れを表すためのダイアグラムです。
近藤：そうですね。一部のオブジェクト指向の本によると、ＤＦＤなどはオブジェクトの概念とは反対のものなので、あまり使わないように薦めています。しかし、私の経験では、それは参考にはなりますが、まったくその通りにやる必要はないかもしれません。
ユースケース図は、やはり開発するシステム機能に早く集中する傾向があり、開発対象とするシステム外のほかのシステムや要素とのつながりが漏らしてしまうことがあるようです。また、ユースケース図はシステムの範囲を決めるべきだが、システム開発の初期では、範囲をはっきり決めるのはなかなか難しいこともよくあります。
山田：そうですか。
近藤：そのため、全ての人が理解できる、システムを一枚の図で表すようなものが必要です。これにはコンテキスト図が向いています。ここで言うコンテキスト図は一種のＤＦＤですが、システム外（そと）とのデータのやり取りのみを記述し、システム内部のデータについては何も記述しないものです。また、コンテキスト図は、ユーザー側の企画書などにすでにある場合は、それをチェックして、開発側で流用できるケースもあると思います。
そうすると、この前言ったように、ユースケースが顧客とのコミュニケーションに使われるというのとちょっと矛盾するようにおもわれますが、やはり現実には、同じようなものの違った表現が必要です。
山田：どうもありがとうございます。コンテキスト図に関してはわかりました。ところで、各ユースケースで出てきた概念や名前など名詞は、これからはクラスになると聞きましたが、そうでしょうか？
近藤：それの答えはＹｅｓでもありＮｏでもありますね。各ユースケースで現れた名詞はクラスになる可能性が十分ですが、必ずクラスになるかどうか、いまの時点ではまだわかりません。そのため、コンセプト図を導入することが必要だと思います。
田中：コンセプト図とは？
近藤：コンセプト図は一種のクラス図ともいえますが、分析レベルのものです。普通のクラス図ではクラスの属性と操作などの記述が必要ですが、ここではおもに名前だけを整理した図になります。とういうのは、基本的にはユースケースから出てきた名詞を整理したうえで、重要な意味をもつ名詞、あるいはオブジェクトらしい名詞をリストし、それらの名詞の間の関係をつけてみます。その目的は、重要な概念をみつけ、重要ではない概念を捨てることです。コンテキスト図と同じように、できるだけ、一枚の図でこのシステムの重要な概念をお客様にみせたほうがいいと思います。
田中：わかりました。われわれもコンセプト図を書きましょう。
それと、ユースケース記述を表すためにシーケンス図を使うこともできるでしょうか？
近藤：そうですね。クラス図と同じように、シーケンス図でも分析レベルと実装レベルの区別があると思います。一般的にいうと、実装レベルのシーケンス図はオブジェクト間のメッセージ通信です。しかし、分析段階ではオブジェクトそのものがまだはっきりしていないので、オブジェクト間のメッセージ通信より、システムの流れを表します。言い換えると、ユースケース記述の替わりに、図で表現するものです。われわれは、このようなシーケンス図をシナリオ図とよんでいます。シナリオ図の主な特徴は明確的なオブジェクトはもっていません。
田中：大体、かんじはつかめましたが、まだ十分に理解できていないようです。例で説明してもらえますか？
近藤：わかりました。
たとえば、「車両の注文書」を作成するというユースケースでは、その流れは、以下のようになっている。
・お客様の注文情報を入れて、
・システムがデータベースから対応する見積情報を引き出し、
・その見積情報に基づいて注文書のデータを纏め、また今回注文の情報を付け加え、
・最後にそのお客さんの注文書を作成し、
・確認したうえで、印刷する。
このような流れをシナリオ図で表すことができます。
田中：わかりました。これからは、われわれもユースケースリスト、コンテキスト図、コンセプト図、および一部のシナリオ図を書いてみましょう。
鈴木：それがいいでしょう。がんばりましょう。