다음을 통해 공유

アーキテクチャ設計におけるモジュール化（２）

  • 아티클

前回の説明の中でモジュール化という言葉を出しましたが、この定義について誤解を生まないように少し説明を加えましょう。モジュール化とは、モジュールを作るという意味ですが、ここでのモジュールは.NETでのアセンブリー、あるいは、JavaでのJARのように物理的な配布のためのパッケージではありません。これらは、配布、インストール、運用時の構成管理（セキュリティ設定など）、物理レベルの資産のバージョン管理のための単位です。一般的には、機能の単位、保守の単位、再利用の単位、配置の単位に利用されます。これらは、物理的形式（ファイル）ですので、プラットフォームや実装に依存します。

一方、ここでのモジュールは、論理レベルの成果物（モデル）に対する単位をいいます。主に可変性の単位で、内部のモデルはほぼ同一の変更の度合いを持っています。分かりやすく言えば、コードの変更の例で、データベースのスキーマにカラムの追加を行う場合、それを処理するデータアクセスコードやロジック、UIの変更も必要となる場合があります。これらの変更はすべて一貫性を持ってなければならず、テスト検証の上、チェックインされます。変更はアーキテクチャのレイヤーにまたがる複数の箇所で起こり、この範囲を表現するのがここでのモジュールです。

モジュールは適切は配布のためのパッケージに関連づけられます。まずモジュールが定義され、そして配置のためのパッケージ化に対応づけられます。それぞれが別の構成定義、バージョン管理されます。

このモジュールはおわかりのように、アーキテクチャのレイヤー（論理的なコンポーネント）構造とは複雑な関係にあります。両者は依存関係は持っていますが、モジュールからアーキテクチャに対して一方向の依存関係があり、その点では、アーキテクチャを先行的に設計しますし、モジュール化の定義の仕方にアーキテクチャの設計は影響を受けません。

このモジュールはまた別の特徴としてパラメータをとります。パラメータによりモジュールを構成定義可能として可変性を持たせるといってもいいでしょう。実際には、パラメータはアーキテクチャの拡張部分に作用してアーキテクチャの構成を可変にしたりもします。このパラメータの設定をXMLやプログラムで行ってもいいですし、DSLのようなツールを使って行ってもいいです。

さて、こうして作られたモジュールをアーキテクチャを使うことを前提としたプロジェクトで再利用していきます。あるプロジェクトでは、モジュールAとBをそれぞれパラメータ設定して再利用し、別のプロジェクトではモジュールAとCをまた別のパラメータ設定して再利用します。

ここで疑問なのは、こうしたモジュールの再利用が有効となるかどうかという点です。いままでもコンポーネントの再利用があまり有効でなかったのに、モジュールにしたからといって同じように有効とならないのではという疑問です。もっともな疑問でしょう。

モジュールがコンポーネントと異なる点は3つあります。

1つは、要求に対してあらかじめドメイン分析を行い、どのような可変性が必要かを分析してスコープを決めている点です。したがって、ここでもモジュールはこのスコープ内に有効性は限定されます。この限定により、再利用性を高めようとします。

第2として、可変性を持たせることにより再利用を決め打ちにしていないことです。完成したコンポーネントは適用範囲を狭めますが、モジュールは可変性をプログラム可能な領域まで広げることで再利用性を高めようとしています。

第3として、これが一番大切なことですが、モジュールは再利用の状況を見てリファクタリングされるという点です。当初のプロジェクトでモジュールの定義があまり有効でない場合は、その後のプロジェクトでは、モジュール定義を変更して再利用性を高めます。しかし、この場合でもアーキテクチャとの一方向性の依存関係により、アーキテクチャには変更がないようにします。アーキテクチャの保守は別の観点で行うべきだからです。

こうしたモジュールを可変性を表現するフィーチャ（特性）モデルに対応づけます。つまり、要求からフィーチャを構成定義します。フィーチャはモジュールに対応づけられているので、フィーチャの構成定義はつまり実装の構成定義になります。要求は実現されるわけです。

この前提にはアーキテクチャはドメイン分析で作られること、そして、プロジェクトで繰り返し利用される長期の資産であることが求められます。いままでのようなワンオフ開発ではありません。ですので、ワンオフ開発が投資的に有利な場合の話ではありません。

モジュールは要求を構成定義するフィーチャから使われ、適切にリファクタリングされるという前提では、その存在理由から100%の再利用性を持ち得ます。

これがソフトウェアプロダクトラインです。請負型のワンオフ開発をやっている限り再利用性を高めるには限界があることを理解されたでしょうか。ソフトウェアプロダクトラインは請負型をプロダクト（パッケージ）開発型にする手法です。また、そうでないければ、大部分のソフトウェア開発の未来は明るくないと思っています。

要求に時間をかけることは大切ですが、同じくらい設計にも時間をかけるべきでしょう。日本の現状は、要求やプロジェクト管理に行き過ぎていて、設計や開発手法の有効性について見落としているのではないでしょうか。この方面ではまだやることが多くあり、それらの改善はプロジェクト管理よりも生産性に寄与し、品質にも大きく貢献できると思っています。