クラス図とは何ですか？
UMLのクラス図は、オブジェクト指向モデリングの基盤となる構造的設計図です。クラス、その内部属性（データフィールド）、メソッド（関数）、およびそれらの間の構造的関係を可視化することで、ソフトウェアシステムを把握します。コードベースが広大になり、解析が難しくなる場合でも、明確なクラス図はエンジニアに、コードオブジェクトがどのように相互作用し、振る舞いを継承し、データ境界を管理しているかを即座に視覚的に示す参考資料を提供します。
使用してVPasCode、あなたはプレーンテキストだけで詳細なクラスレイアウトを設計でき、レイアウト工学、ボックスサイズ、行間隔はすべて、統合されたクラウドエンジンに完全に任せることができます。
コア構文ガイド：要素と構造
高品質なクラス図を書くには、3つのコア構造的マーカーを理解する必要があります：クラス本体の定義、メンバーへの可視性修飾子の割り当て、オブジェクト関係のマッピング。
1. クラスとメンバーの宣言
標準的なオブジェクト設計図を、classキーワードを使って宣言します。末尾の波かっこ内に、フィールドとメソッドを別々の行に記述します：
class CustomerAccount {
String accountId
String emailAddress
Boolean isActive()
}
2. 可視性修飾子（アクセス制御）
PlantUMLは、標準的なオブジェクト指向カプセル化ルール（public、private、protected、およびパッケージプライベート）を、フィールドまたはメソッド名の直前に簡単なテキスト接頭辞を使ってマッピングします：
+明確なパブリックアクセス（他のすべてのクラスからアクセス可能）-厳密なプライベートアクセス（この特定のクラス内でのみアクセス可能）#プロテクトアクセス（このクラスおよびそのサブクラス内でアクセス可能）~パッケージ/内部アクセス（ローカルコードモジュール内でのみアクセス可能）
3. オブジェクト関係の定義
クラスを接続するには、アプリケーションコードの構造的依存関係または構成を示すために、特定の矢印記法が必要です：
- 継承／一般化（Is-A）：親クラスを指す開いた三角形の矢印頭を使用する：
SubClass --|> ParentClass - 実装／実現：インターフェースの実行を示すために点線と開いた三角形を使用する：
ConcreteClass ..|> IInterface - 合成（厳格な所有権）：子オブジェクトが親コンテナなしでは存在できないことを示すために実線のダイヤモンドを使用する：
Parent *-- Child - 集約（共有コレクション）：一時的なコレクション関係を示すために開いたダイヤモンドを使用する：
Department o-- Employee
実用的なクラス図のためのベストプラクティス
- 抽象クラスでレイアウトを分離する：
abstract classまたはinterfaceキーワードを用いて、構造的境界を具体的なデータベースモデルから視覚的に区別する。 - 多重度を早期にラベル付けする： 常に数値の多重度（例：
"1"または"0..*"）を関係の矢印の両端に追加して、開発者にとってデータ制約を明確にする。 - 垂直方向の間隔を制御する： クラス図は非常に高くなることがある。レイアウトが垂直方向にあまりに伸びる場合は、二重ダッシュ（
--）を単一のダッシュ（-) を関係の矢印内に記述することで、横方向の並べ替えを強制します。
実際の PlantUML クラス図の例
例 1: オンラインショッピングドメインモデル（可視性とカプセル化）
この設計図は、標準的なアクセス修飾子、基本的なデータオブジェクト、および主要なオンラインショッピングエンティティ間の基本的なデータ多重性マッピングを示しています。
@startuml
class User {
- String userId
- String hashedSecret
+ Boolean verifyLogin(String input)
}
class Order {
+ String orderId
+ Date timestamp
- Double calculateTotal()
}
User "1" --> "0..*" Order : "注文を発注し所有する"
@enduml
構文の分解： - プレフィックスは、認証情報などの機密フィールドを、User クラスブロック内に厳密にプライベートに保ちます。一方、パブリックアクセス関数は+ マーカーを使用します。接続文字列は、1人のユーザーがゼロ個または複数の注文をスムーズに参照できることを明確に示しています。
例 2: 高度な決済ゲートウェイ（継承とインターフェース）
この包括的なソフトウェアエンジニアリングのマップは、統一されたフレームワーク内でインターフェース、クラスの継承ループ、複雑な構成をどのように整理するかを示しています。
@startuml
interface IPaymentProcessor {
+ Boolean authorizeAmount(Double cash)
+ void captureFunds()
}
abstract class BaseGateway {
# String merchantApiKey
# String endpointUrl
+ void logTransaction(String payload)
}
class StripeGateway {
- String stripeToken
+ Boolean authorizeAmount(Double cash)
+ void captureFunds()
}
class PayPalGateway {
- String paypalEmail
+ Boolean authorizeAmount(Double cash)
+ void captureFunds()
}
class ShoppingCart {
- List items
+ void checkout(IPaymentProcessor engine)
}
' 構造的関係宣言
BaseGateway ..|> IPaymentProcessor
StripeGateway --|> BaseGateway
PayPalGateway --|> BaseGateway
ShoppingCart *-- IPaymentProcessor
@enduml
構文の分解： ..|> 表記は、抽象クラスが主なルートインターフェースを実装していることを確立します。実線の三角形（--|>）は、子ゲートウェイが基底の親クラスに明確に接続されることを示します。一方、実線のダイアモンド（*--）は、ショッピングカートセッションのライフサイクル中に、基本的にはその決済エンジンプロセッサを所有している。