トピック

定義 ページの先頭へ

ソフトウェアの業界と文献では、「コンポーネント」という用語をさまざまな意味で使用しています。多くの場合は、「構成要素」という広い意味で使用されます。大規模システムで置換や組み立てを可能にする特定の特性という狭い意味でもよく使用されます。

RUP で「コンポーネント」という用語を使用する際は、カプセル化されたシステムの部分を意味します。理想的には、重要で、ほぼ独立していて、置換可能なシステムの部分であり、明確に定義されたアーキテクチャーの中で明瞭な機能を果たすものを意味します。例えば、次のものがあります。

  • 設計コンポーネント - 設計のカプセル化された重要な部分であり、設計サブシステムを含み、重要な設計クラスと設計パッケージを含むこともある
  • 実装コンポーネント - 実装のカプセル化された重要な部分であり、通常は設計コンポーネントを実装するコード

設計が実装を反映し、コンポーネントだけで設計と実装を備えていることが理想です。

UML ([UML04]) はコンポーネントを次のものとして定義します。

内容をカプセル化し、外側に現れる部分は環境内で置き換え可能である、システムのモジュール部分。コンポーネントは、提供される必要なインターフェースという観点で、振る舞いを定義します。したがって、コンポーネントは、提供される必要なインターフェースによってその適合性が定義される、型として機能します (静的および動的なセマンティクスを包含します)。

コンポーネントを構造化されたクラスのサブタイプとして定義すると、属性と操作を備え、関連および汎化に関与することができ、内部構造とポートを持つコンポーネントを規定できます。詳細については、『概念: 構造化されたクラス』を参照してください。

コンポーネントに適用される複数の UML 標準のステレオタイプが存在します。例えば、<<subsystem>> は大規模なコンポーネントをモデリングし、 <<specification>> および <<realization>> は仕様および実現を明確に定義してコンポーネントをモデリングします。1 つの仕様が複数の実現を持つ場合もあります。

RUP ではコンポーネントという用語を UML の定義より広い意味で使用します。モジュール性、導入性、置換性などの特性を持つものとしてコンポーネントを定義するのではなく、これらをコンポーネントの望ましい特性として推奨します。コンポーネントの置換性については、次のセクションを参照してください。

コンポーネントの置換性ページの先頭へ

RUP と UML の用語では、コンポーネントは置換可能である必要があります。ただし、この意味は、コンポーネントが基礎となる実装を隠すインターフェースのセットを公開するということだけかもしれません。

その他にも、より強い種類の置換性があります。これを次に示します。

ソース・ファイルの置換性

2 つのクラスが 1 つのソース・コード・ファイル内に実装される場合、通常は各クラスのバージョン管理とコントロールを別個に行うことはできません。

ただし、1 セットのファイルが 1 つのコンポーネントを完全に実装し、他のコンポーネントを実装しない場合は、このコンポーネントはソース・ファイル置換可能です。この特性により、コンポーネントのソース・コードのバージョン管理、ベースライン化、再利用が容易になります。

導入の置換性

2 つのクラスが 1 つの実行可能コード内に導入される場合、導入されたシステム内で各クラスを別個に置換することはできません。

粒度の大きいコンポーネントに望ましい特性は「導入の置換性」であり、これにより、他のコンポーネントを作成し直すことなく新しいバージョンのコンポーネントを導入できます。通常、この意味は、そのコンポーネントを導入し、他のコンポーネントを導入しない 1 つまたは 1 セットのファイルがあるということです。

実行時の置換性

実行中のシステムにコンポーネントを再導入できる場合は、「実行時の置換性」があるといいます。その場合、利用可能性を失わずにソフトウェアをアップグレードできます。

位置の透過性

ネットワーク・アドレス可能なインターフェースを持つコンポーネントは、「位置の透過性」があるといいます。その場合、コンポーネントを他のサーバーに再配置するか、複数のサーバー上にコンポーネントを複製するか、フォールト・トレランスやロード・バランシングなどをサポートすることができます。この種類のコンポーネントは多くの場合、「分散」または「分散可能」のコンポーネントと呼ばれます。

コンポーネントのモデリングページの先頭へ

UML コンポーネントは、次の機能を提供するモデリング構成要素です。

  • クラスをグループ化して、粒度の大きいシステムの部分を定義できる
  • 可視のインターフェースを内部の実装から分離できる
  • 実行時に実行するインスタンスを持つことができる

コンポーネントには、規定される必要なインターフェースが複数あり、コンポーネントを結び付けるための基礎となります。規定されるインターフェースは、コンポーネントまたはコンポーネントが実現するクラスまたはサブコンポーネントの 1 つによって直接実装されます。すなわち、 コンポーネントの規定されるポートのタイプです。必要なインターフェースは、 コンポーネントまたはコンポーネントが実現するクラスまたはサブコンポーネントの 1 つから使用する依存関係によって指定されます。すなわち、必要なポートのタイプです。

コンポーネントには、public 可視性を持つプロパティーと操作による外部ビュー (すなわち「ブラック・ボックス」ビュー) があります。オプションとして、プロトコルの状態マシンのような振る舞いをインターフェース (ポート) およびコンポーネントそれ自体に付加し、操作の呼び出し順序に動的な制約を明示して、より精密に外部ビューを定義することができます。システムまたは他のコンテキスト内でのコンポーネント間の結びつきは、(一般に、コンポーネント図で) コンポーネント・インターフェース間の依存関係を使用して構造的に定義できます。

オプションとして、コラボレーション構造のより詳細な仕様を、複合構造のパートとコネクターを使用して作成し、コンポーネント間での役割またはインスタンス・レベルのコラボレーションを指定できます。これは、private 属性のプロパティーおよび実現するクラスまたはサブコンポーネントによる、コンポーネントの内部ビュー (すなわち、「ホワイト・ボックス」ビュー) です。このビューでは、外部の振る舞いを内部的に実現する方法が示されます。外部ビューと内部ビューの間のマッピングは、依存関係 (コンポーネント図で)、または内部パートへの委任コネクター (複合構造図で) によって行います。

RUP では、設計サブシステムの表現にコンポーネントを使用することを推奨します。 詳しくは、『成果物: 設計サブシステム』、『作業: サブシステム設計』および『ガイドライン: 設計サブシステム』を参照してください。また、『概念: 構造化されたクラス』の定義を参照してください。

コンポーネントのインスタンス化ページの先頭へ

コンポーネントは、実行時に直接インスタンス化できる場合と、できない場合があります。

間接的にインスタンス化されたコンポーネントは、クラス、サブコンポーネント、またはパートのセットによって、実装すなわち実現されます。コンポーネント自体は、実装に現れません。実装が従わなければならない設計として機能します。 実現するクラス、サブコンポーネント、またはパートのセットは、規定されるコンポーネントのインターフェースで指定された操作全体のセットを網羅していなければなりません。コンポーネントを実装する方法は、実装担当者の責務となります。

直接インスタンス化されるコンポーネントでは、固有のカプセル化された実装を指定します。この場合、アドレス可能なオブジェクトとしてインスタンス化されます。これは、設計コンポーネントが、実装言語に対応する構造を持つことを意味するので、明示的に参照可能です。

UML 1.x の表現ページの先頭へ

UML 1.5 はコンポーネントを次のものとして定義します。

システムの導入と置換が可能なモジュール部分。実装をカプセル化し、一連のインターフェースを公開します。通常、コンポーネントは、そのコンポーネント上の 1 つまたは複数のクラスあるいはサブコンポーネントによって指定され、1 つまたは複数の成果物 (バイナリー・ファイル、実行可能ファイル、スクリプト・ファイルなど) によって実装されます。

UML 1.3 とそれ以下のバージョンの UML では、実装内のファイルを表すために「コンポーネント」の表記を使用していました。最新の UML の定義では、ファイルを「コンポーネント」とは見なさなくなっています。ただし、多くのツールや UML プロファイルでは、ファイルを表すために現在でもコンポーネントの表記を使用してしています。UML でのファイルの表現方法について詳しくは、『ガイドライン: 実装要素』を参照してください。

モデリングの観点から見ると、コンポーネントは UML 1.5 での UML サブシステムに匹敵するものでした。なぜなら、モジュール性、カプセル化、実行時に実行可能なインスタンスを備えているからです。RUP では、UML 1.5 コンポーネントがモデリングする構造を、設計サブシステムを表現するための代替の表記法と見なしています。詳しくは、『成果物: 設計サブシステム』および『ガイドライン: 設計サブシステム』を参照してください。

詳しくは、『UML 1.x と UML 2.0 の相違点』を参照してください。

Rational Unified Process   2003.06.15