[ Java Project Exampleページへ戻る ]
時刻プログラム開発の基本構想を練る。といっても大雑把なものだけど。
プログラムで時刻を扱うときは、たいていマシンクロックを取ってくる。でも、これでは都合がわるいことがある。例えばシミュレーションゲームやロールプレイングゲームを作っている場合、その時刻とは現実の時間の流れではなく、プレイの中で流れる仮想的な時間だ。場合によっては暦自体も現実とは異なるだろう。宇宙暦、神聖暦、帝国暦、とか。
また、パソコンを触っていると時間を忘れてしまうことがある。何の時間かはいろいろあるだろう。TV番組だったり会議だったり。ある時間がきたことを知らせてほしいことがある。
そこで、いろいろなプログラムから利用できる時刻プログラムを作成することにした。
まずは現時点で漠然と思っている時刻プログラムに対する要望を列挙してみる。
時刻プログラムの開発方法を決める。これを決めないと次の作業が決まらない。伝統的な(?)開発方法では、まず要求分析を行い、時刻プログラムの仕様を厳密に定義するだろう。しかし、現時点で時刻プログラムがどうあるべきかなんて分からない。要望は使ってみればもっと出てくるしね。
そこで、作って評価して、また作って評価して、と小さいものから始めて繰り返し開発を行っていくことにする。イテレーション（繰り返しの1つのサイクル）では、そのイテレーションが終わったときにどんなプログラムが動作しているかを最初に定め、設計を行い実装しテストを行う。イテレーション終了ごとに、プログラムがリリースされる。
RUPっぽくもあり、XPっぽくもあるけど、あまり意識しないで気軽にやっていこう。
このイテレーションが終了する時に、どんなプログラムが動いているべきかを定める。オブジェクト指向の教科書的にはユースケースを書くのだろうし、XP(eXtreme Programming)ではストーリーやタスクを書くのだろう。でも最初は特に書式を定めず自由に始めていく。
パッケージ、クラスは設計することにしたい。Javaでプログラムを書くときにどうせ考えねばならないのだし、パッケージ階層って結構重要だし。細かいシーケンスは書かないでおこう。
コードはきれいに書きたいなぁ。Javadocでドキュメントも生成したい。
ユニットテストはしよう。統合テストはどうするかなぁ。だんだん大きくなってきたらちゃんと試験をしないといけないだろうね。
これは後々重要になるだろうな。人様に配布するならバージョンは付けないと混乱するし、インストール方法や起動方法が難しいと使う気が起きないし。
開発言語、マシン、ミドルウェアやライブラリ、開発支援ツールといったものを決めて用意しないといけない。
やっぱJavaでしょう。
手持ちのマシンということで、Windows2000のPC。Linuxでも動くプログラムであってほしい。
別にDBMS(DataBase Management System)を使うほどでもない。ネットワーク越しでも使うので、分散オブジェクトは使うだろう。Webサービスにするメリットはなさそう。具体的な製品は各イテレーションで選定・評価することになろう。
車輪の再発明は避けたいので積極的に使っていく。何が必要になるかは各イテレーションで決めればよいだろう。
設計用のUMLツール、エディタ、コンパイラ、ビルドツール、プロファイリングツール、デバッガ、テストツール、インストーラ、ドキュメント生成ツール、などなど。これも各イテレーションで選定すればよいだろう。
プロジェクト途中での変更はあるにせよ、これをきちんと整えておかないと一貫性がなくなってしまう。
図を記述するならUMLに従う。特に最新版を追っかける必要もないので、多くのツールが対応しているUML1.1以上にする。最初は手書きで十分かな。
Java 2 Standard Edition, Ver. 1.4にする。
なじみのある"Writing Robust Java Code v1701d"を採用。必要に応じてプロジェクトでカスタマイズすることになろうが、これはイテレーションの都度固めていく。
Sunの"Java Code Conventions (日本語訳)"はJosh Bloch氏によれば、あまり保守されておらず、Sunの中でそんなに使われていない。Sun謹製だからっていいわけではないってこと。
オブジェクト倶楽部のJavaコーディング標準はコーディングの指針が多く含まれ参考になる。
構成管理の最低限として、成果物（ベースライン）を決めることと、成果物のバージョン管理を行う。成果物としては、ソースコード、設計図、ドキュメント、リリースしたプログラムなどがある。
バグをきちんと管理してないと。バグの登録、修正、解消をちゃんと管理しておこう。