PlantUML コンポーネント図の構文ガイド

コンポーネント図とは何ですか？

A コンポーネント図は構造的な UML図は、ソフトウェアシステムの高レベルなモジュール構成を明示するものです。統合モデル言語（UML）仕様の重要な構成要素として、この特定の UML図タイプ物理的なコードモジュール、ライブラリ、マイクロサービス、実行パッケージ、データベースレイヤーがどのように構造的にグループ化され、相互に接続されているかを可視化します。詳細なクラス定義から文書化の焦点を逸らし、ソフトウェアアーキテクトや主要エンジニアがシステム統合境界、APIオーケストレーション経路、サードパーティ依存関係を明確に示すことができます。

現代のクラウドネイティブマイクロサービストポロジーを概説する場合でも、または内部フレームワークライブラリがレガシーなアプリケーションコアにどのように接続されているかを示す場合でも、UMLコンポーネントマップはシステム境界の明確で構造的な概要を提供します。VPasCodeにより、コンポーネントレイアウトは宣言的なテキストに基づいて自動的に描画され、レイアウトボックスや接続線を手動で調整する手間が省けます。

コア構文ガイド：要素と構造

PlantUMLで洗練され、標準準拠のUMLコンポーネント図を設計するには、モジュール化されたコードブロック宣言、インターフェース接続メカニズム、システムパッケージグループ化、方向性接続パラメータを習得する必要があります。

1. ソフトウェアコンポーネントの宣言

ソフトウェアモジュールは、componentキーワードを使用して宣言します。あるいは、明確なテキスト識別子を角かっこ（[コンポーネント名]）で囲むこともでき、これはグローバルな省略記号として機能します：

component PaymentEngine
[Auth Service] as AuthService

プロのヒント：長いコンポーネント文字列は、常に as識別子（例：as AuthService）を併用して、関係線を明確で読みやすく保ちましょう。

2. ポートとインターフェースの定義

コンポーネントは構造的エントリポイントを通じて互いにやり取りします。標準のUMLインターフェース（クリーンな「ラムネ」のような円アイコンで視覚的に表現される）を明示的にモデル化するには、インターフェースキーワードを使用します：

インターフェース "REST API v2" as WebAPI
[AuthService] --() WebAPI : "公開する"

3. コンポーネントの依存関係のマッピング

あるシステムモジュールが別のモジュールに依存しているか、通信していることを示すには、方向性のある矢印（-->）を使用します。また、標準の点線の依存関係ライン（..>）を使用して、メッセージキューの消費パターンや一時的なランタイム呼び出しのような緩い関係を表現できます：

[Frontend App] --> WebAPI
WebAPI ..> [Database Engine] : "SQLクエリ"

4. パッケージによる境界の整理

明確なサブシステムの境界を設定する、またはデプロイ環境に基づいてコンポーネントを分類するには、モジュールブロックを構造的なパッケージまたはクラウドラッパーで囲みます：

パッケージ "セキュリティコンテキスト" {
    [認証サービス]
    [トークン検証サービス]
}

クリーンなコンポーネントサブシステムのためのベストプラクティス

• ノード名は高レベルに保つ： 特定の内部コードファイルやディレクトリ名に従ってコンポーネントを命名しないでください。機能的で高レベルの名前（例：）を使用してください。[通知ルーター] または [キャッシュレイヤー].
• ラリポップ表記を活用する： ボックスの間を単純な線で結ぶのではなく、明示的な インターフェース ノードを通じて接続をルーティングする。これにより、*どの*インターフェースが公開されているか、*誰が*それを使用しているかが明確に区別される。
• レイアウトの拡張を制御する： 複数のサブシステムを追跡する際、コンポーネントマップは急速に拡大する。依存関係の矢印内に空間的フラグ（例：-right-> または -down->）を使用して、コンポーネントをキャンバスグリッド上で明確に整理する。

実世界のPlantUMLオブジェクト図の例

例1：コアAPIゲートウェイメッシュ（インターフェースとパッケージグループ化）

このテンプレートは、標準的なマルチティアシステムのWeb設定を示しており、パブリックユーザー・アプリケーションが構造化されたREST APIインターフェースを通じて内部のマイクロサービスに接続される仕組みを強調している。

@startuml
package "公開プレゼンテーションレイヤー" {
    [Web SPAクライアント] as client
    [Mobile iOSクライアント] as mobile
}

package "APIゲートウェイサブシステム" {
    interface "HTTPSゲートウェイエンドポイント" as HTTP_GW
    [Kong APIゲートウェイ] as gateway
}

package "コアバックエンドサービス" {
    interface "ユーザー管理API" as UserAPI
    interface "請求API" as BillingAPI
    
    [アイデンティティサービス] as auth
    [支払い処理エンジン] as billing
}

' プレゼンテーションからゲートウェイへの接続
client --> HTTP_GW
mobile --> HTTP_GW
HTTP_GW -- gateway

' ゲートウェイからバックエンドインターフェースへの接続
gateway --> UserAPI
gateway --> BillingAPI

UserAPI -- auth
BillingAPI -- billing
@enduml

構文の分解： クリーンな package バウンダリー内にモジュールをネストすることで、自動レイアウトエンジンは美しく明確なゾーンを生成する。プレゼンテーションクライアントは、単一の公開された HTTP_GW ゲートウェイポートにのみ接続され、その後、下位の専門的なバックエンドマイクロサービスレイヤーへの内部トラフィックルーティングを管理する。

例2：クラウドデータ処理パイプライン（非同期クラウドとキュー）

この高度なエンタープライズブループリントは、現実世界の非同期クラウドデータアーキテクチャをマッピングしており、インジェストパイプライン、分離されたメッセージブローカー、物理的なストレージエンドポイントを追跡している。

@startuml
cloud "AWSクラウドネットワーク境界" {
    [インジェストWebhook] as webhook
    queue "Apache Kafkaクラスタ" as broker
    [ストリームプロセッサイベントワーカー] as worker
    database "Amazon S3データレイク" as storage
}

database "企業データウェアハウス" as redshift

' プロセッシングパイプラインのフロー仕様
[外部クライアントアプリ] --> webhook : "POST /telemetry"
webhook -right-> broker : "生ログの公開"

broker ..> worker : "トピックデータストリームの消費"
worker --> storage : "圧縮されたParquetファイルの書き込み"

storage ..> redshift : "毎夜のETL同期"
@enduml

構文の分解： この例では、特別な cloud および queue 形状を導入しており、開発者に構造的なトポロジーについて即座に視覚的な手がかりを提供します。水平矢印のオーバーライド -right-> を使用することで、データインジェストがネットワークグリッド上で左から右へスムーズに流れることを保証します。一方、点線の依存関係（..>）は、分離された非同期通信を正確に表現しています。