---
title: UMLクラス図からPython実装を考える
tags:  #uml  
author: [Yukiko](https://image.docswell.com/user/yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/9E298NL57R.jpg?width=480
description: UMLクラス図からPython実装を考える by Yukiko
published: October 14, 26
canonical: https://image.docswell.com/s/yukiko_it/58NE12-2026-10-14-214045
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/9E298NL57R.jpg)

PEER-REVIEWED × OFFICIAL SPEC で読み解く
UMLクラス図から考える
Pythonオブジェクト指向実装
「設計図を読める人」になるための文系向け入門講座
査読済み実証研究 × OMG公式仕様 × Python公式ドキュメント に基づく構成
うさうさ研修工房 ｜ 監修：うさうさ先生


# Page. 2

![Page Image](https://bcdn.docswell.com/page/D7Y46PQ6EM.jpg)

GOAL OF THIS SESSION
この講座で身につくこと
図とPythonコードの対応関係が見える
UMLクラス図の「読み方」がわかる
1
2
箱・線・記号 1つひとつに意味があることを理解する
「この図なら、このコードになる」という感覚をつかむ
査読済み研究に基づき「伝わる図」を説明できる
公式ドキュメントを自分で調べられる
3
4
なぜその書き方が良いのか、根拠を持って人に話せる
OMG仕様・Python公式サイトへの入り口を持ち帰る
対象読者：エンジニアではないが、要件定義や仕様レビューでクラス図・コードに触れる方
うさうさ研修工房｜UMLクラス図からPython実装を考える
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/VENYZ521J8.jpg)

WHAT IS UML
そもそも「 UML」とは何か
• UML（Unified Modeling Language / 統一モデリング言語）は、ソフトウェアの
設計を「図」で表すための世界共通の記法
• 策定・管理しているのは OMG（Object Management Group） という国際標準
化団体
UMLダイアグラムの主な種類
クラス図
オブジェクト図
ユースケース図
シーケンス図
状態遷移図
アクティビティ図
コンポーネント図
配置図
• クラス図はUMLの中でも「システムの静的な構造（何がどう関係しているか）」
を表す代表的な図
• つまりクラス図＝『設計の共通言語で書かれた仕様書の一部』
公式仕様（ OMG UML 2.5.1 Specification）
★ このスライド以降は「クラス図」に焦点を当てて学びます
https://www.omg.org/spec/UML/
うさうさ研修工房｜UMLクラス図からPython実装を考える
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/Y79PZY1YE3.jpg)

WHY IT MATTERS FOR NON-ENGINEERS
なぜ「文系」のあなたにも必要なのか
エンジニアとの共通言語になる
1
「その属性、publicですか？」が通じると仕様確認の齟齬が激減する
仕様書・要件定義の解像度が上がる
2
「モノ」と「モノの関係」で要件を捉えられるようになる
動くコードの裏の設計思想が見える
3
コードレビューの議事録や設計書を読んでも迷わなくなる
ノーコード時代でも「構造を考える力」は不変
4
ツールが変わっても、要素と関係を整理する力は資産になる
うさうさ研修工房｜UMLクラス図からPython実装を考える
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/G78D164K7D.jpg)

THE THREE-COMPARTMENT BOX
クラスは「 3段の箱」で描く
① クラス名
「これは何の設計図か」を表す名前。多くの場合、
名詞1語（Book, User, Order …）で表す。
Book
+ title : str
+ author : str
+ price : int
② 属性（Attributes）
そのクラスが「持っているデータ」。 Pythonでは
self.属性名 になる。
+ lend()
+ return_book()
③ 操作（Methods）
そのクラスが「できること」。 Pythonでは def メソッド
名(self): になる。
ポイント：どの言語で実装しても、この3段構造の「意味」は変わりません。
うさうさ研修工房｜UMLクラス図からPython実装を考える
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/L7LMQ96PJR.jpg)

VISIBILITY NOTATION
属性・操作の前の記号 ＝「見える範囲」
記号
意味（ UML）
説明
+
public（公開）
どこからでもアクセス可
self.title
-
private（非公開）
クラスの内部だけで使う
self.__title
#
protected（保護）
自分と子クラスだけで使う
self._title
~
package（限定公開）
同じパッケージ内だけで使う
（Pythonに直接の対応なし／モジュール内
での慣習で表現）
うさうさ研修工房｜UMLクラス図からPython実装を考える
Pythonでの表現
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/4EMY1Z52EW.jpg)

FROM BOX TO CODE
箱の中身を、そのままコードにする
book.py
Book
+ title : str
+ author : str
+ price : int
+ lend()
+ return_book()
• 属性 → __init__ の中で self.〇〇 に代入する
対応
class Book:
def __init__(self, title: str, author: str, price: int):
self.title = title
# 属性①
self.author = author
# 属性②
self.price = price
# 属性③
def lend(self):
# 操作①
print(f&quot;{self.title} を貸し出しました&quot;)
def return_book(self):
# 操作②
print(f&quot;{self.title} が返却されました&quot;)
• 操作 → def 名前(self): のメソッドになる
• 「+」は公開なので、そのまま素直な名前で OK
うさうさ研修工房｜UMLクラス図からPython実装を考える
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/PER9L635J9.jpg)

ASSOCIATION &amp; MULTIPLICITY
関連（Association）— クラス同士の “つながり ”
Customer
1
注文する
+ name : str
0..*
Order
+ order_id : str
読み方： 1人の Customer は、0件以上（ 0..*）の Order を持つことができる
customer.py
class Customer:
def __init__(self, name: str):
self.name = name
self.orders = []
# 0..* の関連はリストで表現する
def place_order(self, order):
self.orders.append(order)
うさうさ研修工房｜UMLクラス図からPython実装を考える
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/P7XQWM4XEX.jpg)

AGGREGATION vs COMPOSITION
集約 vs 合成 —「分身できるか」で見分ける
集約（ Aggregation）
Team
Player は Team が解散しても存在し続けられる（弱い所有）
合成（ Composition）
Player
Car
Engine は Car と生成・破棄を共にする（強い所有＝一心同体）
集約：外から受け取る
合成：自分で生成する
class Team:
def __init__(self, players: list):
# 外部で作られた Player を
# 受け取って持つだけ＝集約
self.players = players
class Car:
def __init__(self):
# Car の中で Engine を
# 自分自身が生成する＝合成
self.engine = Engine()
うさうさ研修工房｜UMLクラス図からPython実装を考える
Engine
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/37K9VGZ97D.jpg)

GENERALIZATION / INHERITANCE
継承（Generalization）—「〜の一種である」
Animal
+ speak()
中が空洞の三角形（▷）は「親クラス（スーパークラス）」の方を向く
Dog
+ speak()
Cat
+ speak()
inheritance.py
class Animal:
def speak(self):
raise NotImplementedError
class Dog(Animal):
def speak(self):
return &quot;わん！&quot;
# ( ) の中に親クラスを書く＝継承
うさうさ研修工房｜UMLクラス図からPython実装を考える
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/LJ3WMND9J5.jpg)

DEPENDENCY &amp; REALIZATION
依存・実現 — 点線矢印が示す関係
依存（ Dependency）
Order
実現（ Realization）
PaymentGateway
«interface»
StripeGateway
PaymentGateway
+ pay(amount)
一時的に「使うだけ」の弱い関係（引数として受け取る等）
「型（インターフェース）」の約束ごとを実装する関係
def checkout(order, gateway: PaymentGateway):
gateway.pay(order.total)
from abc import ABC, abstractmethod
class PaymentGateway(ABC):
# 抽象基底クラス＝interface役
@abstractmethod
def pay(self, amount): ...
class StripeGateway(PaymentGateway):
def pay(self, amount): ...
線はどちらも点線。先端が「白抜き三角形」なら実現（interfaceの実装）、「開いたV字矢印」なら依存。
うさうさ研修工房｜UMLクラス図からPython実装を考える
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/8JDK6WP8EG.jpg)

PUTTING IT ALL TOGETHER
総合演習 — ECサイトの注文システムを設計する
Customer
1
+ name : str
Order
0..*
OrderItem
1..*
+ order_id : str
+ checkout()
«interface»
PaymentGateway
+ qty : int
+ pay(amount)
StripeGateway
+ pay(amount)
────
関連（Association）：Customer は複数の Order を持つ
◆────
合成（Composition）：Order が OrderItem を生成・保有する
- - -＞
依存（点線・開いた矢印）：Order は決済処理を PaymentGateway 経由で利用する
うさうさ研修工房｜UMLクラス図からPython実装を考える
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/VEPKY9NW78.jpg)

FROM DIAGRAM TO CODE
図から書き起こした Pythonコード
payment.py / order_item.py
customer.py / order.py
from abc import ABC, abstractmethod
class Order:
def __init__(self, order_id: str,
gateway: PaymentGateway):
self.order_id = order_id
self.gateway = gateway
# 依存
self.items = []
# 合成
class PaymentGateway(ABC):
# «interface»
@abstractmethod
def pay(self, amount: int): ...
class StripeGateway(PaymentGateway): # 実現
def pay(self, amount: int):
print(f&quot;{amount}円を決済しました&quot;)
class OrderItem:
def __init__(self, product: str, qty: int):
self.product = product
self.qty = qty
うさうさ研修工房｜UMLクラス図からPython実装を考える
def add_item(self, product, qty):
self.items.append(OrderItem(product, qty))
def checkout(self, total: int):
self.gateway.pay(total)
class Customer:
def __init__(self, name: str):
self.name = name
self.orders = []
# 関連
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/27VVGMK97Q.jpg)

EVIDENCE-BASED DIAGRAM DESIGN
査読済み研究に見る「伝わるクラス図」のコツ
① 記法は「統一」してこそ伝わる
同じ意味を表すのに書籍やツールごとに異なる書き方が使われている実態があり、読み手の正確な理解を妨げる一因になりうると報告されている。
出典： Purchase, Colpoys, McGill &amp; Carrington (2001), Australian Symposium on Information Visualisation
② レイアウトの美しさは理解のしやすさに関係する
線の交差の少なさなどグラフ描画の美的基準と、人がクラス図を理解する精度・速さとの間に関係があることが実験で示されている。
出典： Purchase, McGill, Colpoys &amp; Carrington (2001), Australian Symposium on Information Visualisation
③ 意味のあるグルーピングが理解を助ける
役割ごとにまとまりを作るレイアウト（多クラスタ配置）は、単純な配置と比べて構文・設計の両方の理解課題で高い成績につながったと報告されている。
出典： Sharif &amp; Maletic (2009), IEEE International Conference on Program Comprehension
→ 本資料の図が「左から右へ」「役割ごとにグループ化」して描かれているのはこの知見に基づく設計判断です。
うさうさ研修工房｜UMLクラス図からPython実装を考える
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/5JGL8GQ47L.jpg)

OFFICIAL SOURCES &amp; REFERENCES
一次情報にあたるための参考リンク
公式仕様・公式ドキュメント
OMG UML 2.5.1 Specification
https://www.omg.org/spec/UML/
Python公式ドキュメント：クラス
https://docs.python.org/ja/3/tutorial/classes.html
Python公式ドキュメント： abc（抽象基底クラス）
https://docs.python.org/ja/3/library/abc.html
査読済み参考論文
Purchase, H. C., Colpoys, L., McGill, M. &amp; Carrington, D. (2001). UML class diagram syntax: An empirical study of comprehension. Australian Symposium on Information Visualisation.
Purchase, H. C., McGill, M., Colpoys, L. &amp; Carrington, D. (2001). Graph drawing aesthetics and the comprehension of UML class diagrams: an empirical study. Australian Symposium on
Information Visualisation.
Sharif, B. &amp; Maletic, J. I. (2009). An Empirical Study on the Comprehension of Stereotyped UML Class Diagram Layouts. IEEE 17th International Conference on Program Comprehension (ICPC).
うさうさ研修工房｜UMLクラス図からPython実装を考える
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/47QY9XKREP.jpg)

まとめ
• クラス図は「3段の箱（クラス名・属性・操作）」と「線（関係）」で読む
YourNextClass
• 線の種類（実線／点線、矢頭の形、菱形）が関係の“強さ”と“種類”を表す
• 属性・操作はほぼそのまま Python の self. と def に対応する
+ ???
• 読みやすい図の書き方には、査読済み研究による裏付けがある
+ ???()
次の一歩
身近な業務（顧客管理・予約・在庫など）を1つ選び、「箱」と「線」で描いてみましょう。うまく描けない箇
所こそ、業務理解が深まる伸びしろです。
うさうさ研修工房 ｜ 監修：うさうさ先生


