┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.72 2004/12/01
■ I N D E X
┃
┣【Topics】クリスマスイベント参加登録、締め切り間近です
┣【新発想】オブジェクト指向の再定義[5] - テストと進捗
┣【プログラミング】C#で学ぼうオブジェクト指向入門 [最終回]
┗【アンケート】気になるシステム業界 ホントのところ
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 クリスマスイベント参加登録、締め切り間近です
〇 〇━━━━━━━━━━━━━ ━━・
12月9日(木)に開催します、オブジェクト倶楽部クリスマスイベント。たくさん
の参加受付、本当にありがとうございます。3日(金)が参加受付締め切りです。
プロジェクトの状態と相談して受付を保留していたあなた!いよいよ決断のと
きです。参加後には、上手にオブジェクト指向開発をドライブする何かが、きっ
と見えているはずです!
詳細はこちら:http://www.objectclub.jp/event/2004christmas/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【新発想】オブジェクト指向の再定義[5] - テストと進捗
今回は、テストと進捗管理(その2)である。Alistair Cockburn は、ソフト
ウェア開発の「一個流し」(*1)と進捗管理について、おもしろい例を出してい
る。次の問題を考えてみて欲しい。
30個の部屋がある豪邸を考える。この豪邸から、1ヵ月後に引越しをするこ
とに決めた。全部屋を掃除し、捨てるものと運ぶものに分類し、ダンボー
ル箱に詰めなければならない。どのように進捗を管理したら、1ヶ月とい
うデッドラインを守れるか。
■ウォーターフォール的計画:
1.最初の1週間で全部屋の掃除を行なう。
2.次の1週間で全部屋の捨てるものと運ぶものを分類し、ステッカーを家具や
備品に貼る。
3.次の1週間で全部屋のダンボール箱詰めを行なう。
4.次の1週間で全部屋のチェックを行なう。
5.4週間あるので、4週間後には全部屋のチェックまで終わる。
■一個流し的計画(すなわち、アジャイルな計画):
1.日割りで、1日に1つの部屋を、掃除、分類、箱詰め、チェックまで終える。
2.30日あるので、30日後には全30部屋の箱詰めが終わる。
さて、上記2つの方法で進捗を管理した場合、どちらが確実に遅れを察知でき、
対策を取りやすいだろうか。
ウォーターフォール的計画での見積もりは根拠が難しい。また、分類は実はす
ぐに終わるが、箱詰めに思ったより時間が掛かることが分かった場合、その知
識を活かすことができない。分かったときには時既に遅しだ。
これに対して、「一個流し」は進捗をリニアに管理できる。そして、この一個
流し戦略をビジュアルにマネジメントするツールが「バーンダウンチャート」
だ。30個が一個ずつ減っていく計画をたて、それを日々追っていく。以下の写
真は、バーンダウンチャートの例。1イテレーションの中で完成させるべきソフ
トウェアの要求を縦軸にとっている。青が予定線、赤が実績線だ。
http://www.ObjectClub.jp/ml-arch/magazine/magazine72/burndown-2-small.JPG
前回の繰り返しになるが、「テストで進捗を測る」。テストの終了に到達して
いないものは「在庫」と考える。在庫状態にある成果物を減らし、バリュース
トリーム(価値の流れ)の速度を上げるのだ(平鍋)。
(*1)「一個流し」は、トヨタ生産方式用語。ソフトウェアに対応づけると、
ウォーターフォール式にすべての要求を一度にまとめて分析・設計・実装・テ
ストと工程を進めるのではなく、要求を小さな単位で1つずつ、分析からテスト
まで流すこと。
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった:
http://www.ObjectClub.jp/cgi-bin/question.cgi?K001+4+0
普通:
http://www.ObjectClub.jp/cgi-bin/question.cgi?K001+4+1
イマイチ:
http://www.ObjectClub.jp/cgi-bin/question.cgi?K001+4+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【プログラミング】C#で学ぼうオブジェクト指向入門 [最終回]
■はじめに
この記事は、初級開発者である私がみなさんと一緒にC#を使ってオブジェクト
指向(OO)の基礎を気軽に勉強していこう、という内容です。
C#でオブジェクト指向の入門について一通り説明しましたので、今回で最終回
にさせて頂きます。ご了承ください。
■目標
今回はCondition属性についての理解を目標に学習していきたいと思います。C#
の属性はクラス、フィールド、メソッドに情報を付加し、ドキュメント生成や
コンパイルの制御などに使われます。
では実際にプログラムを書いて確認していきましょう。
■内容
まずは、コンディション属性がついたメソッドのあるクラスを見てみましょう。
====< Logger.cs >====================================================
using System;
using System.Diagnostics;
namespace Log
{
public class Logger
{
[Conditional("DEBUG")] // ★1
public static void Message(string message)
{
Console.WriteLine("[{0}] : {1}",DateTime.Now, message);
}
}
}
=====================================================================
----< コンパイル方法 >-----------------------------------------------
csc /target:library /d:DEBUG Logger.cs
---------------------------------------------------------------------
★1の[Conditional("DEBUG")] のように、Condition属性をメソッドに付加する
ことで条件付きメソッドにすることができます。Condition属性では、パラメー
ターを1つ指定しますが、ここでは"DEBUG"としています。このパラメーターが、
Loggerクラスを利用する側でメソッドを挿入するかどうかを制御する識別する
ものになります。
次に、Loggerクラスを利用する側を見てみましょう。
====< Hello.cs >======================================================
using System;
using Log;
public class Hello
{
public static void Main(string[] args)
{
Logger.Message("Main Starting");
Console.WriteLine("Hello {0}!!", args[0]);
Logger.Message("Main Ending");
}
}
=====================================================================
コンパイル時にコンパイラ オプションで/define:DEBUGを付けるか否かで、
Log.MessageメソッドがHello側で挿入されたり、されなかったりします。
/define:DEBUGとコンパイラ オプションをつけてして、コンパイル→実行した
場合は、
----< コンパイル、実行方法 (DEBUG あり)>--------------------------
csc /reference:Logger.dll /define:DEBUG MainApp.cs
MainApp.exe ienaga
[2004/11/22 18:58:21] : Main Starting
Hello ienaga!!
[2004/11/22 18:58:21] : Main Ending
---------------------------------------------------------------------
のように、Starting、Endingは表示されます。
コンパイラ オプション付けずに、コンパイル→実行した場合は、
----< コンパイル、実行方法 (DEBUG なし)>---------------------------
csc /reference:Logger.dll MainApp.cs
MainApp.exe ienaga
Hello ienaga!!
---------------------------------------------------------------------
のように、Starting、Endingは表示されません。
プログラム内の条件分岐(if)により制御するのではなく、コンパイル時にコン
パイラオプション(/define:DEBUG)でによって制御しているのがCondition属性
の特徴です。
■まとめ
Condition属性について学習しました。プログラムを制御する際に、開発時、
運用時で振る舞いを制御したいなどの際に、それを直接条件分岐で記述すれば
コードが煩雑になってしまう場合があります。そんな場合、Condition属性を使
えばコードをシンプルにすることができます。
.NETでは、Condition属性のほかにも標準で、
・メソッドが古くなったことを示すObsolete属性、
・オブジェクトがシリアル化可能であることを示すSerializable属性、
・外部からDLLをインポートするためのDllImport属性
などが用意されています。
C#で属性を使う機会と言えば、NUnitの単体テストではないでしょうか。
・クラスにテストメソッドを含むことを示すため、クラスにTestFixture
属性
・テストメソッドであることを示すため、メソッドにTest属性
がその代表的な属性です。(ちなみにJUnitの場合は、TestCaseを継承したクラ
スがテストメソッドを含むテストクラス、メソッド名がtest××のものがテス
トメソッドになるようになっています。)
また説明は省かせて頂きましたが、独自に属性を宣言することも可能です。
Condition属性のようにコード自身を制御したいと思われたら、一度属性につい
て調べてみてはいかがでしょうか。
■終わりに
年が明けてからは、言語をC#からRubyにかえ、Rubyの特徴を学習するだけでは
なく、実際にRubyを使ってTDDやパターンなどについても皆さんと一緒に学習し
て、更なるパワーアップをしていきたいと思っています。
お楽しみにー。(IENAGA)
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった:
http://www.ObjectClub.jp/cgi-bin/question.cgi?E003+12+0
普通:
http://www.ObjectClub.jp/cgi-bin/question.cgi?E003+12+1
イマイチ:
http://www.ObjectClub.jp/cgi-bin/question.cgi?E003+12+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗【アンケート】気になるシステム業界 ホントのところ
今週は「状態遷移図が好き」のホントのところ。読者の 方からのリクエストで
す。ありがとうございます。状態遷移の記述といえば、UMLの『状態遷移図』が
有名だと思いますが、『状態遷移表』もまだまだ健在です。みなさんはどちら
の表現形式がお好きですか?
状態遷移図のほうが好き。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+37+0
状態遷移表のほうが好き。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+37+1
両方好き。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+37+2
両方好きじゃない。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+37+3
どちらでも良い。。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+37+4
状態遷移図、状態遷移表ってなに?
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+37+5
それは秘密です。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+37+6
ちょっと語らせて!
editors@ObjectClub.jp まで詳細を!!
アンケート結果はオブジェクト倶楽部サイト上にて公開します。お楽しみに。
なお、前号「ソーシャル・ネットワーキングがお好き」の結果は公開中。是非
ご覧下さい。⇒http://www.ObjectClub.jp/special/kininaru
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。モバイルSuica ってご存知ですか?2005年度後半か
らの開始される、Suica機能(JR東日本のプリペイドカード、定期券、ショッピ
ング機能)を搭載した携帯電話です。この携帯電話の通信機能により、駅の販
売機を利用しなくても、プリペイドカードの入金や定期券購入、自動改札機の
入出場や、提携店での買い物ができるようになるそうです。世の中、どんどん
シームレスになってすごいですね。きっと読者の皆さんの中にも、このような
シームレスな環境を実現するシステムに携わっている方がいらっしゃることで
しょう。システムを作るのではなく、手間を省く、便宜性を向上させる環境を
作ってるんですよね。これまたすごいことですよね。
今週の強引な一言
*** 画竜点睛を欠く(故事成語)***
開発当初は、きちんとユニットテストを書いていても、終盤にさしかかるとプ
レッシャーから、つい手抜きになっていませんか。手抜きをしたところから崩
壊が始まるものです。最後まであきらめずに、完璧を目指していきましょう。
(さとみ)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒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.