本日から、第4章コンポーネント図に入って行きます。
初回の今日は、コンポーネント図の概要についてお話致します。
第4章 コンポーネント図
４−１ コンポーネント図概要
４−１−１ コンポーネントとは
コンポーネントは、単純なものから複雑なものまで、様々な規模のシステムを規定することが出来ます。
コンポーネントは、第3章で扱ったカプセル化クラスを継承します（サブクラスです）。
つまり、ポートやインターフェースを用いて内部構造を持つことが可能です。
そして、コンポーネントは、構造化分類子と同様に、インターフェースの規定する条件さえ合えば、どのような環境下でも活動することが可能です。
逆に言いますと、構造化プログラミングが一般的になる以前の、スパゲッティのようにこんがらがったソフトウエアの内部構造を記述するには不向きともいえます。
これは、コンポーネントという概念そのものに、モジュラー構造が前提としてあり、オブジェクト指向開発の根本概念にカプセル化あるいは情報隠蔽があることからも、当然の帰結といえます。
また、現在のシステム開発の前提として、契約に基づく開発（CBD: Contract Based Development)の考え方ありますが、その2つのスローガン、「変更はクローズに」と「拡張はオープンに」を忠実に再現するための手段という位置づけもあります。
CBD(契約に基づく開発）
▼ ❑ 「変更はクローズに」：
変更は内部だけで行い、外部環境に影響を及ぼしてはならない
▼ ❑ 「拡張はオープンに」：
拡張は外部環境に対し、上位互換性を保つ形で行う
コンポーネントは大きく分けて2種類あり、1つは論理的コンポーネント（ビジネスコンポーネント、プロセスコンポーネント）で、もう一つは物理的コンポーネント（EJBコンポーネント、CORBAコンポーネント、.NETコンポーネント等々）です。
通常これら二種類のコンポーネントを混在させて使うことはなく、論理的コンポーネントは主にシステム開発の上流工程やビジネスモデリングに用いられ、物理的コンポーネントは、実装モデルの設計段階で主に作成されます。
また、コンポーネントは内部に、数多くのステート（状態）や振る舞いを持つ分類子を包含します。
そして、インターフェースを通じて顧客側にサービスを提供したり、またサービスを受け取ったりします。
さらに、インターフェースの条件さえ満たせば、設計時もしくは実行時にコンポーネントを交換することが可能です。（上位互換性）
