ふとしたことがきっかけで、あらためてソフトウェア開発の概念をふりかえり、整理したくなりました。
クラスベースのオブジェクト指向プログラミング言語を使い、設計もクラスが中心となる場合を想定します。関数型プログラミングではなく、Lispでもなく、COBOLでもなく、C/アセンブラでもありません。
ソフトウェアの構成を決める設計ですが、小さいプログラムではいきなりクラスを考えて構成しますが、大きなシステムでは、構成単位として、「サブシステム」、「コンポーネント」、「パッケージ」、「レイヤー」といったクラスよりもっと大きな概念を持ち込むことが多いようです。ところが、この概念をあらためて何ぞやと考えると、どうも世の中に言われているものがみんなそれぞれ異なる概念に見えてしまいました。現状、みんなが口にするこれらの用語は、たぶん十人十色なのではとも思えてきます。
サブシステムについて解説・言及のある記事（抜粋）
@ITの連載記事「The Rational Edge」の記事の一つです。
少々乱暴にいえば、サブシステムとはパッケージとクラスの中間物ということになる。ほかのモデルのエレメントをグループ化するという点では、パッケージのような動作をするが、指定された動作をするという点では、クラスといってもいい。
...略...
サブシステムとパッケージの違いは以下のとおり。すなわち、パッケージの場合にはクライアントは、パッケージ内の複数のエレメントに対して動作の実行をリクエストするが、サブシステムの場合には、サブシステム自身に対して動作の実行をリクエストする。
この連載記事の著者はIBM Rationalのエンジニアなので、RUPの考え方が強く出ていると思われますが、この定義はしっくり来ます。「中間物」については、粒度がパッケージとクラスの間にあるという意味ではなく、パッケージとクラスの性質を両方あわせもつという意味として捉えるのがよさそうです。
では、どこでパッケージを使い、どこでサブシステムを使うのか？と疑問が生じます。
◎アーキテクチャのメリット
・変更からの切り離し
・交換可能な実装
・ダイナミックな交換
・抽象化
・再利用
...略...
◎プロセスのメリット
・詳細デザインの引き延ばし
・並行開発
複数の開発者（開発チーム）で同時に開発作業を進める（並行開発）のために設ける、という視点は、ああ、なるほど、と、思いました。逆に、少数精鋭で全体を作るときは、このメリットは不要ですね。（アーキテクチャのメリットは必要だが）
続きの記事です。
記事の2ページですが、見出し「サブシステムとは」から始まるのでちょうど良い位置です。先の記事と比べると定義が曖昧です。
サブシステムとは、コンポーネントとして独立性の高いパッケージと考えてください。コンポーネントとはソフトウェアの部品です。部品は、必ずインタフェースが決められています。
...略...
サブシステムとはインターフェイスの標準化とブラックボックス化により、ソフトウェアをコンポーネント化（部品化）するための技法です。
第1文は、なんかあやしい定義です。パッケージは独立性が低いのか？ コンポーネントを日本語で訳したら部品となるから定義になっていないのでは、という疑問が生じます。
ただし、以降のこの記事自体は、前述のThe Rational Edgeの記事を踏まえて簡潔に書かれているものです。
サブシステムとは外部に対してインタフェース（CORBAやCOMのインタフェースやJavaのインタフェースクラスと同義です）を持つソフトウェアシステムの下位部品（モジュール）です。
...略...
オーソドックスな方法ではサブシステム構成を考える際にはまずレイヤ構成を考え、各レイヤにサブシステムを配置します。
言葉としては分かった気になりますが、サブシステムを使う根拠なり目的が弱いところです。
ITプロジェクト管理考 というエッセイ集のようなサイトの記事です。
３．コンポーネント化
ソフトウェアを一塊の構造に設計すると、スケーラビリティや拡張可能性、変更容易性がなく技術や市場の変化に追従することが困難になります。ソフトウェア・システムを複数のサブシステムで構成し、また各サブシステムを複数のモジュールで構成することにより、スケーラビリティや拡張可能性、変更容易性を上げる可能性があります。ここに、サブシステムやモジュールをコンポーネントと呼びます。
...略...
しかし、コンポーネントのサイズを小さくしすぎると、分割によってコンポーネントの呼び出しコストが急激に高まり、タイムロスが増大します。
定義はもやっとしていますが、引用の最後の文で、粒度の尺度について述べている点が印象に残っています。全てのクラスにインタフェースを持たせるようなものがその極論の例かもしれません。
