ICONIXプロセスでは、ロバストネス分析が終わったら、実装の設計(シーケンス図作成)に入ります。
ただし、ロバストネス図は、概念設計なので、実装に進むには、実装手段を決めなければいけません。
最も単純なのは、プログラミング言語ですね。大昔であれば決定事項はOSと言語くらいです。あとは、とにかく自分たちでコードを書く。
最近は、特にWebアプリケーションの分野では、大きく状況がかわりました。サーバーとフレームワークを選ぶことで、ソフトウェアの骨格を用意でき、便利な部品がいっぱい手に入ります。
私たちの場合だと、
・Apache
・Tomcat
・Spring MVC
・Web Flow
・Velocity
・iBatis
・PostgreSQL
・Spring Security
などを使っています。
開発ツール類は、Enterprise Architect, Eclipse, Subversion, JIRA, など。
Webアプリケーションを作るために、良く出てくるパターンは、部品が揃っていますから、コードを書く量は激減しました。
例えば、Java では、 for 分を書くことは、ほとんどなくなりました。
データベースから取得したレコードセットを Collection で扱う処理は、iBatis で済ませるので、for 文はいりませんから。 メモリ上のコレクションを for 文で処理することは、ほとんどないですね。
表示の時に、Velecity のテンプレートファイルで、ループさせるくらいかな?
開発は、基本的に以下の作業だけです。
・ドメイン層のクラスの実装
・アプリケーション層のクラスの実装
・iBatis SQLマップファイルで、SQLの定義
・Velocity テンプレートファイル
・Web Flow 定義ファイル
どのクラス名、メソッド名、ID名も、基本的にドメイン(問題領域)の用語だけです。
Spring の定義ファイル内で、フレームワークのクラスやメソッド(つまり技術用語)を一部使いますが、中心ではない。
Spring は、ドメインオブジェクトを活用することを重視しているので、ドメインの分析・設計・実装だけやれば、あとは、お約束に従ってコーディングしておしまい、という感じです。
もちろん、そうなるまでには、フレームワークの選定や習得にだいぶ回り道をしました。
また、今でも、フレームワークのバージョンアップなどは、本番環境も含めると、かなり頭の痛い問題です。
ただ、フレームワークの選定・習得をがんばれば、開発が楽になることは身にしみてわかっていますから、がんばりどころだと思っています。
ICONIXプロセスのガイド本「ユースケース駆動開発実践ガイド」は、アーキテクチャは、Java + Spring なので、私たちにはとても分かりやすかった。
DAO や O-R マッピングのところは考え方が違っていたり、本は jsp で、私たちは velocity とかありますが、たいした問題ではありませんでした。
本や私たちとは違ったフレームワークを使っている人でも、基本はいっしょだと思います。
いずれにしても、シーケンス図(実装設計)の前に、アーキテクチャを確立しておきましょう。
確立するということは、チームで「習熟」しているし、トラブルシューティングの経験・ノウハウもある、ということです。
ただし、ロバストネス図は、概念設計なので、実装に進むには、実装手段を決めなければいけません。
最も単純なのは、プログラミング言語ですね。大昔であれば決定事項はOSと言語くらいです。あとは、とにかく自分たちでコードを書く。
最近は、特にWebアプリケーションの分野では、大きく状況がかわりました。サーバーとフレームワークを選ぶことで、ソフトウェアの骨格を用意でき、便利な部品がいっぱい手に入ります。
私たちの場合だと、
・Apache
・Tomcat
・Spring MVC
・Web Flow
・Velocity
・iBatis
・PostgreSQL
・Spring Security
などを使っています。
開発ツール類は、Enterprise Architect, Eclipse, Subversion, JIRA, など。
Webアプリケーションを作るために、良く出てくるパターンは、部品が揃っていますから、コードを書く量は激減しました。
例えば、Java では、 for 分を書くことは、ほとんどなくなりました。
データベースから取得したレコードセットを Collection で扱う処理は、iBatis で済ませるので、for 文はいりませんから。 メモリ上のコレクションを for 文で処理することは、ほとんどないですね。
表示の時に、Velecity のテンプレートファイルで、ループさせるくらいかな?
開発は、基本的に以下の作業だけです。
・ドメイン層のクラスの実装
・アプリケーション層のクラスの実装
・iBatis SQLマップファイルで、SQLの定義
・Velocity テンプレートファイル
・Web Flow 定義ファイル
どのクラス名、メソッド名、ID名も、基本的にドメイン(問題領域)の用語だけです。
Spring の定義ファイル内で、フレームワークのクラスやメソッド(つまり技術用語)を一部使いますが、中心ではない。
Spring は、ドメインオブジェクトを活用することを重視しているので、ドメインの分析・設計・実装だけやれば、あとは、お約束に従ってコーディングしておしまい、という感じです。
もちろん、そうなるまでには、フレームワークの選定や習得にだいぶ回り道をしました。
また、今でも、フレームワークのバージョンアップなどは、本番環境も含めると、かなり頭の痛い問題です。
ただ、フレームワークの選定・習得をがんばれば、開発が楽になることは身にしみてわかっていますから、がんばりどころだと思っています。
ICONIXプロセスのガイド本「ユースケース駆動開発実践ガイド」は、アーキテクチャは、Java + Spring なので、私たちにはとても分かりやすかった。
DAO や O-R マッピングのところは考え方が違っていたり、本は jsp で、私たちは velocity とかありますが、たいした問題ではありませんでした。
本や私たちとは違ったフレームワークを使っている人でも、基本はいっしょだと思います。
いずれにしても、シーケンス図(実装設計)の前に、アーキテクチャを確立しておきましょう。
確立するということは、チームで「習熟」しているし、トラブルシューティングの経験・ノウハウもある、ということです。