UMLクラス図からPython実装を考える

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

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

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

• https://www.omg.org/spec/UML/

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

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

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

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"{self.title} を貸し出しました") def return_book(self): # 操作② print(f"{self.title} が返却されました") • 操作 → def 名前(self): のメソッドになる • 「+」は公開なので、そのまま素直な名前で OK うさうさ研修工房｜UMLクラス図からPython実装を考える 7

ASSOCIATION & 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

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

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 "わん！" # ( ) の中に親クラスを書く＝継承 うさうさ研修工房｜UMLクラス図からPython実装を考える 10

DEPENDENCY & 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

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

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"{amount}円を決済しました") 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

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

OFFICIAL SOURCES & 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. & Carrington, D. (2001). UML class diagram syntax: An empirical study of comprehension. Australian Symposium on Information Visualisation. Purchase, H. C., McGill, M., Colpoys, L. & Carrington, D. (2001). Graph drawing aesthetics and the comprehension of UML class diagrams: an empirical study. Australian Symposium on Information Visualisation. Sharif, B. & 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

• https://www.omg.org/spec/UML/
• https://docs.python.org/ja/3/tutorial/classes.html
• https://docs.python.org/ja/3/library/abc.html

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