ソフトウェアアーキテクチャとは、キャンバス上のボックスをつなぐこと以上のものである。システムの内部メカニズムがどのように機能し、相互に作用し、一体となって動くかを理解することにある。標準的なクラス図は静的構造の高レベルな視点を提供するが、複雑なコンポーネントの内部トポロジーを記述する際にはしばしば不足する。これがUML複合構造図が不可欠となる理由である。
これらの図は細かい視点を提供し、アーキテクトが内部論理を可視化し、境界を定義し、分類子内での部品の協調方法を明確に指定できる。分散システムを設計している場合でも、モノリシックなアプリケーションをリファクタリングしている場合でも、この表記法を理解することは明確さにとって不可欠である。
🔍 複合構造図の理解
複合構造図は、分類子の内部構造を示すUMLの行動図の一種である。クラスやコンポーネントを構成する部品と、それらの部品間の相互作用に焦点を当てる。標準的なクラス図が属性やメソッドを示すのに対し、この図は構成を明らかにする。
それは部屋の内部の図面だと考えよう。床面図は壁やドアを示すが、複合構造図は家具の配置、配線、異なるゾーンがどのように接続されているかを示す。この違いは、内部動作が外部の成功を決定するシステムにおいて極めて重要である。
なぜこの図を使うのか？
- 内部の可視性：外部インターフェースを混乱させることなく、クラスのプライベート構造を明らかにする。
- コンポーネントの相互作用：内部部品どうしがどのように通信するかを明確にする。
- 境界の定義：コンポーネントと外部世界との境界を明確に示す。
- 再利用：大きなシステム内での再利用可能なサブコンポーネントを特定するのに役立つ。
🧩 図の核心的な構成要素
有効な図を構築するためには、使用される特定の表記法を理解する必要がある。各要素は、システムのトポロジーを定義する上で異なる目的を果たす。
1. 部品（📦）
部品は、複合構造内に含まれる分類子のインスタンスを表す。本質的に構成要素である。クラス図ではこれらは属性となるが、ここでは独自のライフサイクルと振る舞いを持つオブジェクトとして扱われる。
- ステレオタイプ <<part>> を持つ長方形として表示される。
- 全体の中で果たす役割を示すために名前が付けられる。
- 特定のクラスまたはインターフェースとして型付けできる。
2. ポート（🔌）
ポートは相互作用の入出力ポイントである。外部通信が行われる場所と、内部部品が外部世界とどのように接続されるかを定義する。ポートはコンポーネントの機能へのアクセスポイントである。
- 境界に接続された小さな長方形で表される。
- 提供される（機能を提供する）か、必要とされる（機能を必要とする）ことができる。
- 内部実装と外部使用を分離するのを助ける。
3. コネクタ（🔗）
コネクタは部品と部品、部品とポート、またはポートとポートを結ぶ。内部要素間のデータや制御信号の流れを表す。
- 要素を結ぶ線として描かれる。
- 特定のプロトコルまたはデータ型が渡されていることを示すために、タイプを指定できます。
- 各端に多重性制約を定義できる場合があります。
4. ロール (🎭)
ロールは、接続子を介して接続されたときに、部分が示す特定の振る舞いを説明します。1つの部分は、接続の仕方によって複数のロールを果たすことがあります。
- 接続線に配置されたテキストラベル。
- 接続の視点を明確にする。
5. インターフェース (🛡️)
インターフェースは、相互作用の契約を定義します。ポートに接続されたラッパーサンプル（提供されるインターフェース）またはソケット記号（必要なインターフェース）で表されることがよくあります。
📊 比較：クラス図 vs. コンポジット構造図
これらの2つの構造図を混同することはよくあります。以下の表は、適切な使用を確保するための主要な違いを強調しています。
| 特徴 | クラス図 | コンポジット構造図 |
|---|---|---|
| 主な焦点 | クラスおよび関係の静的構造。 | 単一の分類子の内部構造。 |
| 粒度 | 高レベル（システム全体）。 | 低レベル（コンポーネント固有）。 |
| 属性 | データフィールドとして表示される。 | Partインスタンス（オブジェクト）として表示される。 |
| 相互作用 | メソッドを通じて暗黙的。 | ポートと接続子を通じて明示的。 |
| 使用例 | データベーススキーマ設計、一般的なモデリング。 | コンポーネント設計、内部論理フロー。 |
🛠️ コンポジット構造図の作成
効果的な図を作成するには、体系的なアプローチが必要です。単に図形を描いているわけではなく、内部論理の契約を定義しているのです。
ステップ1：分類子の境界を定義する
まず、分類子（例：特定のクラスやコンポーネント）を表すメインの長方形を描き始めます。このボックスが境界として機能します。境界内にあるものはすべて内部です。
ステップ2：内部部品を特定する
この分類子を構成するオブジェクトをリストアップしてください。サブオブジェクトはありますか？ヘルパーサービスはありますか？それらを境界内に配置し、部品として明確にラベル付けしてください。
ステップ3：外部アクセス用のポートを定義する
この分類子がシステムの残り部分とやり取りする場所を特定してください。メインの長方形の境界上にポートを配置し、それが提供されるものか要求されるものかを明記してください。
ステップ4：内部接続をマッピングする
部品の間の線を引いて、それらがどのように相互に通信しているかを示してください。情報の流れを指定するために接続子を使用してください。通信が必要なすべての部品が経路を持っていることを確認してください。
ステップ5：役割とインターフェースを割り当てる
接続に、それらが果たす役割をラベル付けしてください。ポートにインターフェース記号を付けて、通信の契約を定義してください。
🏢 実際のシナリオ：決済処理システム
これを説明するために、決済処理システムを考えてみましょう。単に「決済」クラスを表示するのではなく、その内部ロジックを可視化します。
- 分類子：PaymentProcessor
- 部品：
- TransactionLogger（内部部品）
- SecurityValidator（内部部品）
- GatewayAdapter（内部部品）
- ポート：
- PaymentRequest（要求されるインターフェース）
- StatusUpdate（提供されるインターフェース）
- 接続子：
- PaymentRequestはSecurityValidatorへと流れます。
- SecurityValidatorはGatewayAdapterへと流れます。
- GatewayAdapterはTransactionLoggerへと流れます。
このシナリオでは、図から決済リクエストがゲートウェイに直接行くことはできないことがわかります。検証とログ記録を経由しなければなりません。このロジックは標準のクラス図では隠されていますが、ここでは明確に見えます。
✅ 明確性のためのベストプラクティス
複雑な図はすぐに読みにくくなります。品質を維持するために、これらの原則に従ってください。
- 範囲を制限する：1つの複合構造図でシステム全体を図示しようとしないでください。1つの分類子に集中してください。
- ステレオタイプを使用する：曖昧さを減らすために、標準のUMLステレオタイプを使用して、部品とポートを明確にラベル付けする。
- 重複を避ける：接続線が不要に交差しないようにする。ルーティングを使用して線を整理する。
- 役割を文書化する：方向によって役割が変わる場合は、接続線をラベルなしのままにしてはならない。
- 一貫した命名規則：ドキュメント全体にわたって、ポートと部品の命名規則を一貫させる。
❌ 避けるべき一般的な落とし穴
経験豊富なアーキテクトですら、内部論理をモデル化する際にミスを犯すことがある。これらの一般的な誤りに注意を払うべきだ。
- 部品と属性を混同する：属性はデータを保持する。部品はオブジェクトを保持する。データベース接続文字列を部品インスタンスとして扱ってはならない。
- ライフサイクルを無視する：部品にはしばしば独自のライフサイクルがある。関連する場面では、初期化および終了のロジックが図に反映されていることを確認する。
- 過剰設計：すべてのクラスに複合構造図が必要なわけではない。内部の複雑さがそのオーバーヘッドを正当化する場合にのみ使用する。
- レベルの混同：同じボックス内に内部部品と外部依存関係を混在させてはならない。境界を明確に保つ。
🔄 他の図との統合
複合構造図は孤立して存在するものではない。他のUML図と補完し合い、システムの全体像を構成する。
シーケンス図
相互作用のタイミングを示すためにシーケンス図を使用する。複合構造図は、そのタイミング付きの相互作用を支える静的トポロジーを示す。
アクティビティ図
アクティビティ図は制御の流れをモデル化する。複合構造図は、その制御が内部でどのように流れているかという文脈を提供する。
コンポーネント図
コンポーネント図は高レベルの構造を示す。複合構造図は、そのコンポーネントの内部構成を詳細に分析する。
📝 図の維持管理
ソフトウェアが進化するにつれて、図もそれに合わせて進化しなければならない。更新を怠ると、ドキュメントの負債が生じる。
- コードレビュー：図の変更をコードの変更と同じように扱う。プルリクエストの際に正確性を確認してレビューする。
- リファクタリング: クラスの内部構造をリファクタリングする場合は、図を直ちに更新してください。
- バージョン管理: 図をバージョン管理システムにコードベースと一緒に保存して、履歴を追跡してください。
🔎 深掘り：集約と構成の違い
部品を定義する際、集約と構成の違いを理解することは非常に重要です。
- 構成:強い所有関係。全体が死ぬと、部品も死ぬ。図では、境界によってしばしば示される。
- 集約:弱い所有関係。部品は全体とは独立して存在できる。
モデル化する際は、オブジェクトのライフサイクルと一致する関係を選択してください。この選択は、ポートやコネクタのモデル化にも影響します。
🚀 最後に
内部論理を可視化することは、優れたアーキテクトと素晴らしいアーキテクトを分ける分野です。UML複合構造図は、この分野における強力なツールです。システムが内部からどのように構築されているかについて明確さを強いるのです。
記法を習得し、コンポーネントを理解し、ベストプラクティスを適用することで、開発や保守のための信頼できる地図となるドキュメントを作成できます。ソースコードを読むことなく、高レベルのアーキテクチャと低レベルの実装詳細の間のギャップを埋めることができます。
次に取り組む複雑なコンポーネントにこれらの概念を適用し始めましょう。得られる明確さは、バグの削減と新メンバーのオンボーディングの高速化という恩恵をもたらします。
