| Component図とは |
|---|
| コンポーネントの外部仕様と内部構造を描く図。 |
| Keywords |
| Component |
| コンポーネントとは |
最初に、「コンポーネント」とは何かについて説明しておく必要があるだろう。 その上で、次の項でコンポーネント図の書き方を紹介する。
コン ポーネントという言葉は使う人によって様々な意味で使われ、UML2.0でもまだ完全にその使われ 方が示されているわけではないと考えられるが、UML2.0のSuperstructureのSpecificationには、コンポーネントについて以下の ように記されている。
|
A component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a type, whose conformance is defined by these provided and required interfaces (encompassing both their static as well as dynamic semantics). One component may therefore be substituted by another only if the two are type conformant. Larger pieces of a system's functionality may be assembled by reusing components as parts in an encompassing component or assembly of components, and wiring together their required and provided interfaces. |
コンポーネントとは、システムのモジュラー部品であり、内容物をカプセル 化し、その環境内で取替え可能なものである。 コンポーネントは、provided interfaceとrequired interfaceによって振る舞いを定義する。したがって、コンポーネン トはTypeであり、そのconformanceはこれ らのprovided interfaceとrequired interfaceによって定義される(動的なセ マンティクスだけでなく、静的なセマンティクスもまた包んでいる)。それゆ えに、ひとつのコンポーネントは、適合する型のほかのコンポーネントと取 替え可能である。システムの機能のより大きな要素は、外側のコンポーネン トやコンポーネントの結合物の部 品としてコンポーネントを再利用し、そのコンポーネントのrequired interfaceとprovided interfaceを結ぶことによって結合されることもある。 |
また、この記述のあとに、さらに次のような記述がある。
|
A component is a subtype of Class which provides for a Component having attributes and operations, and being able to participate in Associations and Generalizations. A Component may form the abstraction for a set of realizingClassifiers that realize its behavior. In addition, because a itself Class is a subtype of an EncapsulatedClassifier, a Component may optionally have an internal structure and own a set of Ports that formalize its interaction points. |
コンポーネントはClassのサブタイプであり、このClassはコンポーネントに 対して、属性と操作を持つこと及び関連や汎化に加わる性質を提供している。 コンポーネントは、このコンポーネントの振る舞いを実現するクラシファイ アの セットの抽象物の形をとることもある。また、Classそのものは EncapsulatedClassifier(*)のサブタイプであるので、コンポーネントは任意 で内部構造を持ってもよいし、インタラクション・ポイントを形式化するポー トのセットを持ってもよい。 訳注： |
また、ここで出てくるComponentやTypeといった考え方は、Desmond Francis D'Souzaと Alan Cameron Willsによって提唱されたCatalysis法(「Objects, Components, and Frameworks With Uml: The Catalysis Approach」を参照)の影響をかな り受けている。
| コンポーネントの描き方 |
上記のとおり、コンポーネントは様々な側面を持つので、コンポーネントの書き 方には何通りかある。
ブラックボックス的な書き方
コンポーネントはクラスと同じような長方形の中に描く。
一番上のコンパートメ
ントに、このコンポーネントの名前を書き、
<<component>>というステレオタイプをつけるか、図の右上のよう
な記号をつけるかのどちらかで、この図の表しているものがコンポーネントであ
ることを示す。
その下に<<provided interfaces>>や<<required interfaces>>とステレオタイプを書いたところに記されているのが、この コンポーネントが持つインタフェースである。
また、次のように書くこともできる。
ホワイトボックス的な書き方
上の例では、外側に見せている部分(インタフェース)だけを表現していた。
次の例では、コンポー
ネントを具体的に実現しているものを書く、つまり、中身を見せるホワイトボッ
クスとしての書き方を示す。
<<realizations>>というのは、このクラスの中身としてのコンポー
ネントを指している。
つまり、この例では、FactoryはSubFactory1とSubFactory2とい
う別のコンポーネントによって構成され、このFactoryを実現したJARファイルはFactory.jarであることが<<artifacts>>に示されている。
コンポーネントの中身を描くときは、次のようにも描ける。
前の図と比較すると、前の図がテキストでコンポーネントFactoryを示していたの に比べて、こちらではグラフィカルに内部構造とインタフェースを表現している ことがわかる。