tmp2

8. Which continuous integration system(s) do you use?* CruiseControl?.NET BuildIt?.NET Draco.NET Hippo.NET Other Custom In-house System If 'Other' please specify

 None 

　メッセージングシステムは、システムとシステムの間に簡単なキュー(待ち行列)を置くだけで、異なるアプリケーション間の通信が可能となり、プラットフォームに非依存、ネットワークの場所から独立という利点があります。

　メッセージタイプは大きく分けて2種類ありますが、JMSはその両方をサポートしています。publish/subscribe(pub/sub)は、ニュース購読のイメージです。各メッセージは特定のトピックと関連づけられ、作成者はトピックをpublish、受信者はそのトピックを名指しでsubscribeするかたちです。point-to-point(reliable queuing)は、キューベースで、キューの中に入れておいて、必要に応じてそれを持ってくるというシステムです。メッセージの構成は、JMSの仕様に詳細が載っています。

.NET のアプリケーション アーキテクチャ : アプリケーションとサービスの設計http://www.microsoft.com/japan/msdn/net/bda/distapp.asp

コーディングの知恵を要件定義で利用する http://www.atmarkit.co.jp/farc/rensai/redge32/redge32a.html 要件仕様が順番もバラバラの単なる巨大なリストだったら、これを使うことはできないだろう。実感していようといまいと、要件を集めたものには常に構造がある。要件の構造化にはタイプごとに整理する方法が最適だ。こうすれば、多くの場合はレベルごとに合致するようになる。

　タイプごとの区別を理解するために、保険金請求の申請手続きに必要な4つの要件例を考える。　

未処理請求を減らす必要がある

システムは、請求申請書を自動的にチェックし、適不適を判断する必要がある

請求者が登録済みであるかどうかは、システムがユーザーの社会保障番号で判断すること

システムは最大100件の同時請求処理をサポートすること 　パッと見ると、要件ごとに何か違うと感じるかもしれない。最初のものはかなり高レベルで、システムに一切言及せずビジネスニーズを明示している。2番目はシステムがすべきことを明示しているが、これもかなり高レベルで、直接コードに変換するのは無理がある。3番目の要件は低レベルで、コードを書けるよう、ソフトウェアがすべきことについて十分な詳細を示している。4番目の要件はかなり詳細だが、システムに対して高い処理速度を求めているだけで、システムが処理しなくてはならないことが示されていない。これらは、ユーザーを含むさまざまな関係者に話を聞いて得られる典型的な要件だ。未分類の巨大なリストにこれらすべてをまとめたら混乱するのもうなずけるのではないか。

　要件は、以下のようなカテゴリやタイプに分類するとはるかに便利になる。

ビジネスニーズ

仕様

機能関連のソフトウェア要件

機能以外のソフトウェア要件 　これらは、IBM Rational Unified Process（RUP）で提案されているタイプだ。考えるタイプはこれがすべてではないが、便利なアプローチの一例は表している。どのタイプを利用するかは、プロジェクトの初期段階で判断する。そして、関係者から情報を収集しながら、それがどの要件タイプに当てはまるか判断し、要件を書いていく。

コメントによる詳細説明 http://www.atmarkit.co.jp/farc/rensai/redge32/redge32b.html 優れたコメントとは、コードが何かを処理するときの方法（これはコードを見れば一目瞭然であるはず）ではなく、ユーザー、保守担当者、そして審査担当者がコードの処理内容と品質保証を理解するのに役立つ知識を提供するものだ。同様に、要件にも属性という、要件を理解しやすく、あるいは使いやすくする情報がある。要件を引き出すときは、属性情報も見つけ出す必要がある。重要な属性の一例が、要件がどこから出てきたのかという出所情報だ。情報の出所を把握しておけば、詳しい情報が必要になったときに大幅な時間の節約につながる。もう1つの属性がユーザーの優先事項だ。ユーザーが50件の要件を出してくる場合は、各項目の優先度も伝えてくるはずだ。そうすれば、プロジェクトのスケジュールが進み、すべての要件を満たすには時間が不足することが分かったときに、最低でもどれが最も重要かは分かるようになる。

　自分が書くコードに入れるコメントの書き方に規則がないのと同じように、世界共通の「適切な」属性もない。出所や優先事項はほとんどのケースで有益だが、ほかにも自分のプロジェクトに適したものを明確にすべきだ。要件を収集するときは、システム開発を開始してコードを書き始めたときにチームにとって必要になるかもしれない情報も事前に予想するようにしたい。

宣言要件（「〜すること」などの構造で書かれたもの）には完全な文を用いる。どの文も主語と述語をチェックする。

ガイドラインに従う http://www.atmarkit.co.jp/farc/rensai/redge32/redge32c.html

　要件を引き出すときのもう1つのコツは、誘導尋問のようにならないことだ。ユーザーが何を望んでいるのかはある程度予想できるかもしれないが、それを口にしてしまうと彼らが本当に望んでいるものの実像が見えなくなる可能性もある。そうするのではなく、「どのデータを独立表示させたいですか？」といった自由回答ができる質問をし、「気圧と温度を組み合わせたグラフは欲しいですか？」のような質問は避ける。

◎ 情報隠ぺい

　これは、あるコードのユーザー／コール元は、そのデータの内部にアクセスできてはならない、あるいはその存在も知るべきでない、という原則を指している。データへのアクセスやその修正はファンクションコールを介して行わなくてはならない。こうすれば、コールするプログラムに影響を与えずにデータの内部構造を変更できる。

　これは要件に当てはめても優れた原則で、ユースケースで説明している場合はなおさらだ。先に言及したように、ユースケースにはイベントの流れがある。うまく書かれていないユースケースは、イベントの流れがデータ定義だらけの場合が多い。Manage Purchase Request（購買請求管理）というユースケースのイベントの基本的な流れを見てみよう。

● イベントの基本的流れ

（1） システムが未決購買請求書をすべて表示する

（2） 未決請求書には請求に関する以下の情報が含まれる（文字制限あり）：

　○　承認ID（内部処理用）

　○　注文書番号

　○　参考ID

　○　代理店アカウント略称

　○　ディーラーアカウント名（先頭10文字）

　○　ディーラーアカウント番号

　○　事由コード

　○　請求数

　○　請求日

　○　担当（社内）

　○　コメント指標

（3） 承認責任者は、1）承認、2）拒否、3）キャンセル、4）割り当て、のいずれかを行うことができる。1）承認を選ぶ

（4） すべての作業が終了するまでこれらの処理を繰り返す

　これら15行のうち、11行は未決請求にどのようなデータが関連するのかの説明に費やされている。これは重要な情報だが、ユースケースの中で起こっていることを分かりにくくする。データを別の場所に隠しておく方がよいだろう。そうすれば手順が以下のように変わる。

● イベントの基本的流れ

システムが未決購買請求書をすべて表示する

承認責任者は、1）承認、2）拒否、3）キャンセル、4）割り当てのいずれかを行うことができる。ここでは、1）承認を選ぶ

……すべての作業が終了するまでこれらの処理を繰り返す 　データが別の場所（通常はユースケースの専用要件部分か、あるいは用語解説部分）で定義されていることを示すため、未決購買依頼書は下線が引かれ、斜体で表示される。これにより、本当の機能要件を表すイベントの流れがはるかに読みやすく、理解しやすくなる。

◎ 結合および凝集

　コードを書く場合、結合とはプログラム中の個々のモジュールを可能な限り独立させる、という原則を指す。1つのモジュール内の処理が別のモジュールの内部処理情報に依存してはならない。一方の凝集は、所定のモジュールの中ではすべてのコードが1つの目標の達成に向けて処理を行う必要がある、という原則を指す。これらの原則は、プログラムを理解ならびに保守しやすくする。

　そして、これらの原則は要件、特にユースケースにも当てはまる。ユースケースはスタンドアロンでなくてはならない（結合がまったく、あるいはほとんどない）［*3］。各ユースケースは、機能のほとんどの部分を特定し、システムが関係者に対してどのように価値を提供するのか示す必要がある。関係者に重点を置くことは重要なことだ。その関係者のためにシステムがすることを、ユースケースの順番を気にすることなく明記できる。

　1つのユースケース中の機能は、すべてが関係者の目指す1つの目標達成に向けたものであるべきだ（高い凝集性）。典型的なATMシステムでは、ユースケースの1つは「現金の引き出し」となり、もう1つは「振り込み」となる。どのユースケースも目標は1つに絞られる。これらの機能を1つのユースケースにまとめようとすると、凝集性が低下してしまう（そして望ましくない依存が生じる）。

　しかし、多くのユースケース初心者は、やり過ぎて低いレベルのユースケースをあまりに多く作成してしまうので注意したい。筆者は、「データの修正」などの名称が付いた150のユースケースで構成される銀行の債権回収システム用のモデルを目にしたことがある。このプロジェクトは10人編成のチームで1年がかりの予定だった。しかしこの組織は、ユースケースがあまりに断片的であったため、作業を進行させるに当たって多くの問題を抱えてしまった。彼らは、ユーザーにとっての価値を特定しない低レベルの機能を記述していた。これらは、理解するのが困難で使いにくかった。各ユースケースは非常に凝集性が高かったが、それゆえユースケースは結合性が高かった。このレベルを「債権の回収」といった具体的な処理にまで高めると、凝集性と結合性の両方が適切なレベルになった。

自動化ツールの利用 http://www.atmarkit.co.jp/farc/rensai/redge32/redge32d.html

JSTLを使って日付データを加工する http://www.atmarkit.co.jp/fjava/javatips/128jspservlet46.html

table 変数と一時テーブルの使い分け http://blogs.sqlpassj.org/yoshihirokawabata/archive/2004/06/08/2638.aspx ・table 変数も一時テーブルも、十分なメモリがあれば、メモリ上で処理されます。 ・メモリに入らない場合、tempdb に作成されます。 ・table 変数には、非クラスタ化インデックス、統計情報、INSERT EXEC、SELECT INTO が使えません。 ・スコープは、table 変数では、変数の参照できる範囲、一時テーブルは、セッション範囲。 ・ストアドプロシージャの再コンパイル回数は、table 変数のほうが、一時テーブルより少なくなる。 http://support.microsoft.com/?kbid=305977