想定される開発フロー

これは、冒頭の掲載した図を少し修正したものです。この図の中で、黄色い部分はフレームワークとしてすでに存在しているので、開発を行う必要はありません。開発を行う必要があるのは、第2層の「機能モジュール」と、第3層に属する部分についてのみです。
第2層の開発に関しては、機能モジュールごとに別々の小さなプロジェクトという考え方で望みます。
成果物を今後何度も使用する可能性があるので、それぞれが完全に独立していることを保証するためです。
第3層は従来どおり、ひとつのプロジェクトとして開発します。
それぞれについて、想定される開発フローと、目標を示します。

第2層：機能モジュール開発

例えば、「メール」機能、「掲示板」機能など、どのような案件においても使用する汎用的な機能を案件の開発のたびに毎回新規で開発するのは非効率です。 そこで従来は、他案件から流用し、開発中の案件に合うようにコードを書き換えて利用していました。 しかしこの方法で移植すると、流用元のコードと流用先のコードは似たコードではありますが、同じコードではないという状態になります。 この結果、次のような問題が発生することが予想されます。

• 流用元のコードにバグがあって修正した場合、流用先のコードにも同じ修正を施さなければならない。
• 流用時に修正するポイントがソース内の広範囲にわたるので、流用時の作業が煩雑であり、バグを作りこみやすい。
• 再度機能全体をテストしなければならない。
• 仕様書の流用が難しい。

しかし、機能をひとつのモジュールと考え、最初から再利用が可能な、案件と独立した設計で機能を作成しておくことで、これらの問題をクリアできます。

※テストケースやドキュメントは除く

上の図のように切り分けて開発を行います。
機能モジュールの作成段階では、データベースに関する操作は一切行いません。

機能モジュールの開発では、成果として以下のものが要求されます。

• Action
• ActionForm
• JSP
• Struts-config
• その他

• ビジネスオブジェクトインターフェイス（Home、Entity）

• Home 実装例
• Entity 実装例
• *.db.xml 実装例*1

• ビジネスオブジェクト用の抽象テストケース（案件）*2
• テストスイート

• ユースケース
• ユースケース記述（または詳細設計に準じるもの）
• クラス図（基本レベル、詳細レベル）
• 画面要素表
• 実装ポイント指示書*3
• テスト仕様書
• JavaDoc

このリストを見てわかるとおり、機能モジュールの開発では、実装を行うのはServletAPIやstrutsに関連する部分だけです。 それより深い層、つまりビジネスロジックを定義する層はインターフェイスの定義のみを行います(+抽象テストケースを用意して実装に対する要求も定義しておく)。 もちろん実装が無いと動作テストがおこなえないので、サンプルとして実装は作成しますが、その実装が実際の案件に使われるかどうかはわかりません。(基本的には使われないと考えます)
機能の移植の際、ネックになりがちなのが、使用しているテーブルの設計方針の違いです。 しかしこのようにインターフェイスだけ定義しておけば、実装はテーブル構造にあわせて開発すればよくなります。 またそういった部分がひとつの箇所にまとまっているということも大きなメリットです。

第3層：機能モジュールI/F部分実装

実際には、要求分析→設計段階で当社に蓄積されているものの中に顧客の要求を満たすものがあるならば、それを利用し、なければ新規機能モジュールとして作成というような手順をふむと思われます。
この流れを下の図に示します。

↑クリックで拡大

このようなプロセスを経た結果、ある機能を案件に追加することが決定した場合、機能モジュールの案件への適用作業は以下のようなものになります。

1. 機能モジュールはJARファイルとして保管されています。これを案件のプロジェクトに取り込み、専用のantタスクを使用して展開*4します。
2. 実装ポイント指示書が含まれていますので、これを参考にしながら必要な部分を実装します。
3. ビジネスオブジェクト用の抽象テストケースが含まれていますので、これを継承してテストケースを作成し、ユニットテストを行います。
4. 案件に適応させるため、リンク先変更などの軽微な修正を行います。
5. 動作テストを行います。(これは実際には案件単位でまとめて行います)

※ビジネスオブジェクトのユニットテストが通過しているのに動作テストに失敗する場合は、ユニットテストの精度を上げてみます。 それでも動作しない場合は機能モジュール側にバグがある可能性が高いと考えられます。

このプロセスで要求される成果は以下の通りです。

• ビジネスオブジェクト実装
• *.db.xmlなど

• ユニットテスト仕様書（テストケースのJavaDocで良い）
• 実装箇所のJavaDoc
• テーブル定義書

※機能モジュールを適用した箇所についてのテストについて
機能モジュールを適用した箇所については、すでに機能モジュール開発プロセス内でテストが完了しているため、機能そのもののテストを行う必要はありません。 ただし、案件に適用する際に実装したビジネスオブジェクトのユニットテストは必要です。 これについても機能モジュール開発プロセス内で、抽象テストケースが開発済ですので、不足部分のテストケースを記述し、実行するだけで良いです。 ただし、DB側でストアドプロシージャ、トリガなどを使用した場合にはそれらが稼動する箇所のテスト・テスト仕様書は必要です。

※機能モジュールを適用した箇所についてのドキュメントについて
成果物リストに挙がっていませんが、詳細設計書などはモジュールに付随しているドキュメントを流用できます。

第3層：アプリケーション固有の部分の実装

要件の分析を行った結果、明らかに案件固有であると判断できる部分は、従来どおりの方法で開発を行います。 具体的には、各種マスタの保守画面などがそれにあたります。 ただし、流用の可能性が無いとはいえ、他の機能モジュール的な開発方法を用いるようにします。
ここでの成果としては以下のものが挙げられます。

• Action
• ActionForm
• JSP
• Struts-config
• ビジネスオブジェクト

• ビジネスオブジェクト用のテストケース
• テストスイート

• ユースケース
• シーケンス図（または詳細設計に準じるもの）
• テスト仕様書
• JavaDoc