背景
システムの詳細設計でコンポーネント図を作成する必要があり、Gitで差分管理が可能なコンポーネント図作成ツールを調査した。
記事の目的
PlantUMLでコンポーネント図を作成する
コンポーネント図
コンポーネント図について記載する。
コンポーネント図とは
コンポーネント図は、システム内のさまざまなコンポーネント間の関係を記述したものである。コンポーネント図の描き方
- コンポーネントとインターフェース
@startuml
component Component
() Interface
@endumlコンポーネント図作成時の注意点
コンポーネント図作成時は、下記の8つのポイントに注意する。- 依存を循環させない (Acyclic Dependencies) コンポーネント間の依存関係を循環させてはならない。たとえば、A→B→C→Aという依存は循環するため、認めてはならない。
- 共通性で閉じていること (Common Closure) 同じコンポーネント内のクラスは同種の変更に対して全体として閉じていなければならい。ある変更がコンポーネント内の1つのクラスに影響したとしても、その変更がコンポーネント外のクラスに影響を及ぼしてはならない。言い換えると、複数のコンポーネントにまたがる変更が必要にならないよう、コンポーネント内の凝集性を高めておく必要がある。
- 一緒に再利用されること (Common reuse) コンポーネント内のクラスはまとめて再利用する。コンポーネント内の1つのクラスを再利用する場合には、すべてを再利用する。これも凝集性に関する原則である。
- 依存の逆転 (Dependency Inversion) 抽象概念は詳細事項に依存してはならないが、詳細事項は抽象概念に依存するべきである。
- 開いているが、閉じられてもいる (Open-Closed) ソフトウェア要素は拡張に対して開いているが、変更には閉じられていなければならない。
- リリースと再利用は同じ単位 (Release-Reuse Equivalency) 再利用とリリースは同じ単位で行う。言い換えると、リリースしたソフトウェア要素の一部だけを再利用するべきではない。
- 安定した抽象化 (Stable Abstractions) コンポーネントは抽象的であり、かつ安定していなければならない。コンポーネントは、安定した状態のまま拡張できるよう、十分に抽象的でなければならない。
- 安定した依存関係 (Stable Dependencies) より安定したものに対して依存する。たとえば、コンポーネントAがコンポーネントBに依存する場合、AよりもBの方が安定しているべきである(変更の可能性が低いなど)。
まとめ
- PlantUMLでコンポーネント図を作成する方法を調査、記載した
参考文献
変更履歴
- 2020/05/06: 新規作成
