UMLクラス図の包括的ガイド（図をコードとして）

💡 注記：すべての図は PlantUML形式で提供されています。すぐに以下のツールでレンダリングできます：Visual Paradigm 図をコードとして.

🔹 UMLの紹介

UMLとは何ですか？

「統合モデル化言語（UML）は、ソフトウェアシステムのアーティファクトを指定、可視化、構築、文書化するために使用される汎用的な視覚的モデリング言語である。」 — Rumbaugh他、1999年

主な特徴：

• 🎨 視覚的表記：システムをモデリングするためのグラフィカルな構文

• 📐 標準化：1997年からOMGが採用した標準

• 🔧 方法ではなく言語：プロセスではなく表記を定義する

• 🌐 広範な範囲：ビジネスプロセス、システム機能、コード構造、データベーススキーマをモデル化する

UMLではないもの

🔹 歴史と標準化

進化のタイムライン

1965-1970: Simula-67（最初のオブジェクト指向言語）
     ↓
1970年代-1980年代: Xerox PARCのSmalltalk
     ↓
1984: ブヤルネ・ストロストラップがC++を発表
     ↓
1988-1992: オブジェクト指向手法の普及（ブーチ、OMT、OOSEなど）
     ↓
1994: ランバウがラシオンでブーチと合流 → 統合の始まり
     ↓
1995: UML 0.8ドラフトが公開
     ↓
1996: OMGが標準モデリング言語のRFPを発行
     ↓
1997: OMGがUML 1.1を採用（11月14日）
     ↓
2000: UML 1.3が正式に公開
     ↓
2003: UML 1.5が公開；UML 2.0のスーパーストラクチャが承認

なぜUMLが「メソッド戦争」に勝利したのか

• 50以上の競合するオブジェクト指向メソッドを一つの標準に統合した

• 主要業界プレイヤー（IBM、Microsoft、Oracle、HP）の支援を受けた

• カスタマイズ用の拡張メカニズムを提供した

• オブジェクト指向モデリングの事実上の標準となった

⚠️ 批判的視点一部の意見では、UMLは「委員会によって設計された巨大な言語」であり、初期バージョンでは意味が曖昧であると指摘されている。

🔹 クラスと属性

クラス構造

UMLのクラスは、最大3つのコンパートメントを持つ長方形で表される。

@startuml
class Student {
  firstName: String
  lastName: String
  email[0..1]: String
  encryptedPW: String
  + totalPoints(): Integer
  + setPassword(pw: String)
  + checkPW(pw: String): Boolean
}
@enduml

属性宣言構文

[可視性] 名前[多重度]: 型 [= デフォルト値] {プロパティ}

PlantUMLの例:

@startuml
class Student {
  + ProgramOfStudy[0..2]: String = "MIS"
  - encryptedPW: String {frozen}
  # internalID: Integer
  ~ packagePrivateData: String
}
@enduml

属性スコープ

• インスタンススコープ (デフォルト): 各オブジェクトが独自の値を持つ

• クラススコープ (静的): すべてのインスタンスが共有する単一の値

@startuml
class Student {
  name: String
  {static} count: Integer
}
@enduml

UMLにおけるキー ⚠️

重要な制限: UMLにはキーの概念が組み込まれていない。スタereotypeやタグ付き値を使用して回避する。

@startuml
class Student {
  {pk} id: Integer
  {ak1} email: String
  - name: String
}
@enduml

🔹 関連と関係

基本的な関連と多重度

@startuml
class Exercise
class Chapter
Exercise "0..*" -- "1..1" Chapter : 所属
@enduml

解釈: 各演習は正確に1つの章に属する。章は0個以上の演習を含むことができる。

役割名

関連名の代わりに（またはそれに加えて）、関連の端点に役割名を使用する：

@startuml
class Person
class Company
Person "0..*" --> "0..1" Company : 従業員/雇用主
@enduml

実装: そのPersonテーブルには外部キーが存在するemployer参照するCompany.

移動可能性

矢印で移動方向を指定する:

@startuml
class Exercise
class Chapter
Exercise "0..*" --> "1" Chapter
@enduml

• 矢印は効率的な移動方向を示す

• OODBsでは、片方向のポインタとして実装

• RDBMSでは、結合はどちらの方向でも機能する

コレクション型に{ordered}


@startuml
class Chapter
class Exercise
Chapter "1" -- "0..*" Exercise : {ordered}
@enduml

• {ordered}: シーケンスを維持する（リストを使用、セットではない）

• RDBMSでの実装：順序番号属性を追加

EXERCISES (
    id PRIMARY KEY,
    chapter_id REFERENCES CHAPTERS,
    sort_no INTEGER,
    UNIQUE (chapter_id, sort_no)
)

修飾子

修飾子はキーのようなメカニズムを使って関連するオブジェクトを分割する:

@startuml
class Chapter
class Exercise
Chapter "1" --> "0..1" Exercise : <<qualifier>> no: Integer
@enduml

意味: 章と問題番号が与えられたとき、最大で1つのExerciseが返される。

関連クラス

関連に属性や操作があるとき:

@startuml
class Student
class Exercise
class Solution {
  date: Date
  points: Integer
}
Student "0..*" -- "0..*" Exercise : has solved
Solution .. Student
Solution .. Exercise
@enduml

• 1つのSolution（Student, Exercise）ペアごとに1つのオブジェクト

• 制約：同じ学生が同じ問題に対して2つの解答を提出できない

合成 vs. 集約

@startuml
class Chapter
class Exercise
Chapter *-- "0..*" Exercise : 組成
Chapter o-- "0..*" Exercise : 集約
@enduml

🔹 操作とメソッド

操作宣言の構文

@startuml
class Calculator {
  + getTotal(studID: Integer, inclExtra: Boolean = true): Float {isQuery=true}
  + {static} getInstance(): Calculator
  + {constructor} Calculator(initialValue: Float)
  - recalculate(): void
}
@enduml

パラメータの指定:

[方向] 名前: 型 [= デフォルト値]

• 方向：in (デフォルト), out, inout

• デフォルト値によりオプションパラメータが可能になる

特別な操作のスタereotype

データベースコンテキストにおける操作

文化的な衝突: オブジェクト指向はカプセル化を強調する；リレーショナルは直接的なデータアクセスを強調する。

実装戦略:

🔹 概念化と継承

基本的な概念化

@startuml
class Person
class Student
class Professor
Person <|-- Student
Person <|-- Professor
@enduml

抽象クラスと操作

@startuml
抽象クラス Account {
  - balance: Float
  + deposit(amount: Float): void
  + {abstract} withdraw(amount: Float): void
}
@enduml

一般化制約

@startuml
class Person
class Student
class Professor
class OtherPerson
Person <|-- Student : <<{非重複, 完全}>>
Person <|-- Professor : <<{非重複, 完全}>>
Person <|-- OtherPerson : <<{非重複, 完全}>>
@enduml

多重分類 / 区別子

@startuml
class Employee
class Staff
class Faculty
class HMO
class NonHMO
Employee <|-- Staff : <<種別>>
Employee <|-- Faculty : <<種別>>
Employee <|-- HMO : <<保険>>
Employee <|-- NonHMO : <<保険>>
@enduml

• 区別子は互いに排他的な特殊化をグループ化する

• オブジェクトは各区別子次元ごとに1つの値を持つことができる

🔹 拡張メカニズム

UMLは3つの拡張メカニズムを提供する：

1. ステレオタイプ<< >>

メタモデル要素の新しい「サブタイプ」を作成することで、UMLの意味を拡張する。

@startuml
class Customer <<エンティティ>> {
  - id: Integer
  - name: String
}
class MathLibrary <<ユーティリティ>> {
  + sin(x: Float): Float
  + cos(x: Float): Float
}
@enduml

2. タグ付き値{キー=値}

モデル要素にカスタムプロパティを追加する。

@startuml
class Student {
  {author=sb, version=1.0, persistence=persistent}
  - id: Integer
}
@enduml

3. 制約{...}

自由な形式のテキスト、OCL、または事前に定義された省略語を使用して意味的な制約を追加します。

@startuml
class Exercise {
  - no: Integer
  - points: Integer {value >= 0}
  {points <= maxPoints}
}
@enduml

🔹 データベース設計のためのUML：重要な考慮事項

UMLから関係スキーマへの変換

重要な違い：オブジェクト指向 vs. 関係型

データベース設計者への実用的アドバイス

1. キーを明示的にモデル化する: 使用する{pk}, {ak1}UMLにはネイティブなキー対応がないため、ステレオタイプを使用する

2. 永続性をマークする: 使用する{persistent}データベースクラスと一時的なアプリケーションクラスを区別するためのタグ付き値を使用する

3. 操作を簡素化する: クエリ操作をビューにマッピング；複雑な操作をストアドプロシージャにマッピング

4. 継承を慎重に扱う: クエリパターンに基づいてマッピング戦略を選択する

5. 制約を文書化する: ビジネスルールにはOCLまたは明確なテキスト制約を使用する

6. 関連クラスの使用は慎重に行う: 関係に重要な属性がある場合に限る

🎯 クイックリファレンスチートシート

PlantUMLクラス図表記要約

@startuml
クラス <<ステレオタイプ>> クラス名 {
  {タグ付き=値}
  [+/-/#/~] 名前[多重度]: 型 [= 値] {プロパティ}
  [+/-/#/~] 名前(パラメータ): 戻り値 {プロパティ}
}
@enduml

関連の表記

@startuml
ClassA "multA" -- "multB" ClassB : 関連名
ClassA *-- ClassB  ' コンポジション
ClassA o-- ClassB  ' 聚合
ClassA --> ClassB  ' 可航行
@enduml

可視性記号

• +パブリック

• -プライベート

• #プロテクト

• ~パッケージ

共通のプロパティと制約

• {静的} / {クエリ=true} / {抽象}

• {値 >= 0} / {排他的論理和} / {順序付き} / {主キー}

💡 最終的な考察: UMLクラス図は概念モデル作成に強力ですが、主にソフトウェア工学のために設計されたことを思い出してください。データベース設計にUMLを使用する際は、キー、正規化、宣言的制約といった関係的コンセプトを表現するために、ステレオタイプ、タグ付き値、制約などを用いて記法を拡張する準備をしてください。これらはUMLのオブジェクト指向の基盤には組み込まれていません。

ステファン・ブラス著『Part 6: UMLクラス図』からまとめたガイド。2003年、ハレ大学。すべての図は、現代のツール互換性を考慮してPlantUML構文でフォーマットされています。