┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.71 2004/11/24
■ I N D E X
┃
┣【Topics】クリスマスイベント参加者、好評受付中です！
┣【新発想】オブジェクト指向の再定義[4] - テストの役割：進捗管理
┣【設計】ソフトウェアのお言葉[1] - インタフェースに対してプログラミングせよ
┗【アンケート】気になるシステム業界 ホントのところ
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 クリスマスイベント参加者、好評受付中です！
〇 〇━━━━━━━━━━━━━ ━━・
12月9日(木)に開催します、オブジェクト倶楽部クリスマスイベント。たくさん
の参加登録、ありがとうございます。原田洋子さんにお願いしています、ワー
クショップ「JavaServer Facesなら見える化？」にて、PCによる演習を体験し
てもらえることになりました。「Servletの姫」の下で、実際に手を動かし、
あなたの目で、何が「見える」のかを体験してみてはいかがでしょうか。なお、
「見える化」ライトニングトークスのスピーカも、あと2名の空きがあります。
スピーカは、懇親会の参加費が無料になるという特典付！我こそは！というあ
なた、今すぐご登録ください。
詳細はこちら：http://www.objectclub.jp/event/2004christmas/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【新発想】オブジェクト指向の再定義[4] - テストの役割：進捗管理
テスト容易性(EoT)」と「変更容易性(EoC)」を2つの鍵概念として、良い設計と
は何かを再定義しようとしている。今回は、テストの役割について再考する。
まず、テストとプロジェクト管理の話をしたい（テストとドキュメントの話、
テストとコミュニケーションの話、テストと開発リズムの話、などと続く予定）。
みなさんは、プロジェクト管理の進捗指標として何を使っているだろうか？
「工程ごとに違うが、成果物の完成に対する到達度だ」という答えが一般的だ
と思う。しかし、「設計書90％完成という報告が2週間続いている」というよう
な進捗会議に参加したことがあるはずだ。私が考える進捗管理の基本は、
・中間生産物で計測しない
・明確に0か1かで判断できる計測単位である
・顧客価値で計測する
の3点だ。先に述べた「設計書のページ数」という単位は、3つの条件をどれも
満たしていない。すべての設計書を否定するつもりはないが、設計書は内部の
中間生産物であることが多いし、100％終了という判断もしにくい。特に、「誰
も待っていない」設計書は顧客価値と結びつかない。これでは進捗を「推し量っ
ている(guess)」ようなものだ。
さて、本題のテストにもどる。筆者が提案する最もよい進捗管理の単位は、ア
ジャイル開発で使われている、
「受け入れテストを通った顧客要求の数」
だ。テストは、0か1かのどちらかに倒れる。また、受け入れテストをパスした、
ということは顧客価値に直結する。顧客が求める仕様に対して受け入れテスト
を定義し、これを通過した数で進捗を測ろう。
アジャイル開発では、要求をストーリーという顧客価値の単位に分割し、それ
を「一個流し」する。そして、テストまで通過した要求の数で進捗を測る。全
体を見据えた大きな分析・設計に時間をかけずに、小さな要求単位をテストに
まですばやく流す、ということを繰り返す。この手法は、優先度の高い要求か
ら顧客に早いうちから供給することができるため、最初に全要求を固定する必
要がなく、都度の要求変化に強い。
ウォーターフォール型開発でも、テストで計測することは可能だ。「（弱い）
繰り返し型のプロセスを導入する」、「要求全体を分割して、少しでもいいか
ら優先度の高い要求をテスト工程にまで早く流してしまう」などの工夫ができ
る。また、テストで計測できなくても、「自分の工程の範囲内での顧客（誰が
自分の作業を待っている人）の価値で、計測する」ことによって、進捗管理の
改善ができるはずだ。
テストは目盛り付いたメジャーだといえる。
テストによって、進捗を推し量る(guess)のでなく、進捗を測る(measure）のだ。
（平鍋）
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/cgi-bin/question.cgi?K001+3+0
普通：
http://www.ObjectClub.jp/cgi-bin/question.cgi?K001+3+1
イマイチ：
http://www.ObjectClub.jp/cgi-bin/question.cgi?K001+3+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【設計】ソフトウェアのお言葉[1] - インタフェースに対してプログラミングせよ
こんにちは、天野勝です。
今回から始まるこの連載では、ちまたでまことしやかにささやかれている、ソ
フトウェア開発に関する「お言葉」を、筆者なりの視点で解釈し、その理由や
原因を考えていきます。「よく聞くけど、なぜそうなのか分からない」「いつ
も口にするけど、実は何のことだか分かっていない」「昔はそうだったかもし
れないけど、今の時代ではどうなの」なんていうお言葉はありませんか。そん
なお言葉を理解することで、ちょっとでもソフトウェア開発の本質が見えてき
たらと思っています。
さて、第1回目のお言葉は、「インタフェースに対してプログラミングするので
あって、実装に対してプログラミングするのではない。」[*1]です。筆者は最
初に読んだときは何のことだか、さっぱり分かりませんでした。このときの筆
者の得意言語はVisual Basicや、Lotus Scriptで、言語仕様的にあまりインタ
フェースを意識することがなかったせいかもしれません。Javaも覚え始めたこ
ろで、Javaの言語要素の「interface」は知っていたのですが、それに対してプ
ログラミングするという意味が、分からなかったのです。もしかして、interface
を作成し、それをすべてのクラスにimplementsすることかなと考えましたが、
なんとなくしっくりきませんでした。
で、あるとき分かったのですが、結局どういうことかというと、「クラスやメ
ソッドといったモジュールを利用する場合は、それが内部的にどういった振る
舞いをするかということよりも、何を渡せば何が返ってくるといった契約的な
ことに着目しましょう」ということになります。
当然、利用される側も同じで、その契約が何かをはっきりさせ、それをを満た
すようにプログラミングをすることになります。例えば、Javaではその契約を
interfaceによって切り出すことができます。
具体的に、テストプログラムを使って説明してみます。
public class MapTest extends TestCase {
public void testMap() {
Map map = new HashMap(); //--(1)
map.put("A", "a");
map.put("B", "b");
map.put("C", "c");
Object[] o = map.entrySet().toArray();
assertEquals("A=a", o[0].toString());
assertEquals("B=b", o[1].toString()); //--(2)
assertEquals("C=c", o[2].toString());
}
}
このJavaで書かれたテストプログラムを簡単に説明します。Mapインタフェース
を持ったHashMapクラスのインスタンスを作成し、キーと値のペアを3つ格納し
て、それを順次取り出して、比較をするというものです。
結果は、筆者の環境では(2)のところで、"C=c"が返ってきてしまって表明エラー
となります。値を設定した順番どおりに並んでいません。順番どおりにするに
は、リストの(1)の箇所を
Map map = new TreeMap();
と書き換え、TreeMapクラスのインスタンスを代入するようにします。この修正
により、ABCと値を設定した順番どおりに並びますので、エラーは解消されます。
ところで、これは良いテストプログラムでしょうか。
Mapとして、キーと値のペアを管理して、さらにその並びも順番通りに扱いたい
というのであれば、このプログラムは良くない例となります。インタフェース
の向こうに見え隠れする、実装に対してプログラミングしてしまっているので
す。Mapインタフェースを使っているのであれば、「キーと値のペアを管理する」
以上のことを期待するべきではないのです。これは、契約違反というわけです。
その並びまでも順番通りにしたいならば、(1)の箇所を
TreeMap map = new TreeMap();
として、TreeMapのインタフェース（クラス）を使うようにしたほうが、よりよ
いプログラムになります。先ほどのプログラムは、MapTestではなく、TreeMapTest
というのが妥当でしょう。Mapインタフェースのテストであれば、以下のような
テストプログラムになります（正常系のみ）。
public class MapTest extends TestCase {
public void testMap() {
Map map = new HashMap();
map.put("A", "a");
map.put("B", "b");
map.put("C", "c");
Object[] o = map.entrySet().toArray();
assertEquals(3, o.length); //--(3)
assertEquals("a", map.get("A")); //--(4)
assertEquals("b", map.get("B"));
assertEquals("c", map.get("C"));
}
}
(3)のように数がわかること、(4)のようにキーと対応付けられている値が分か
ることを満たせば、まずは十分なのです。
まとめますと、利用する側は、インタフェースとして決められた契約に従い、
プログラミングをすべきということになります。「インタフェースに対してプ
ログラミングするのであって、実装に対してプログラミングするのではない。」
とは、言い換えると「契約に従ってプログラミングせよ」ということなのです。
今回は、JUnitを使ったテストプログラムを示しました。テストケースが書ける
ということは、インタフェース（仕様）が分かっていることに通じるというこ
とに、気づいていただけたらと思います。
[1]:「オブジェクト指向における再利用のためのデザインパターン」P.30
http://www.amazon.co.jp/exec/obidos/ASIN/4797311126/xpjp-22/
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/cgi-bin/question.cgi?L001+0+0
普通：
http://www.ObjectClub.jp/cgi-bin/question.cgi?L001+0+1
イマイチ：
http://www.ObjectClub.jp/cgi-bin/question.cgi?L001+0+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗【アンケート】気になるシステム業界 ホントのところ
今週は「ソーシャル・ネットワーキングがお好き？」のホントのところ。最近、
各コミュニティーが主催するイベントに参加して、この話題が出ないことはな
い気がします。Orkut、mixi等、色々ありますが、さて、みなさん、ソーシャル・
ネットワーキングお好きですか？
ハマりまくってます。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+36+0
まぁまぁ参加しています。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+36+1
一応参加だけはしています。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+36+2
全く参加していません。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+36+3
そういうの、キライです。。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+36+4
ソーシャル・ネットワーキングってなに？
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+36+5
それは秘密です。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+36+6
ちょっと語らせて！
editors@ObjectClub.jp まで詳細を！！
アンケート結果はオブジェクト倶楽部サイト上にて公開します。お楽しみに。
なお、前号「自分の机の周りにあるパーティションの数は何枚ですか？」の結
果は公開中。是非ご覧下さい。⇒http://www.ObjectClub.jp/special/kininaru
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。飛行機機内でインターネットが利用できるサービス
がJALにて開始されるそうですね。インターネットや携帯電話など、通信情報手
段がどんどん発達し、快適になっていきます。でも、この状況が一切使えなく
なってしまったら、一体私たちはどうなるのでしょう。考えると恐ろしいです。
快適さと引き換えに、失われていくものも、きっとたくさんあるのでしょうね。
今週の強引な一言
*** 学問に王道なし（ことわざ）***
いろいろな技術が出てきて、ついそれに飛びつきたくなりますよね。でも、そ
の技術を使いこなすには、少なからず勉強は必要です。その勉強をせずに、使
えない技術だとレッテルを貼らないように気をつけましょう。
（さとみ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/community/object_ml/help/
〇 免責事項、過去の記事は ⇒http://www.ObjectClub.jp/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表：平鍋 健児
Copyright (c)2003-2004 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.