MaruLaboの浅海ゼミでの講座のスライドです。 https://www.marulabo.net/docs/asami28/ オブジェクト指向モデリングの原理としてSOLIDやGRASPなどが知られています。 5回に渡ってドメイン設計について見てきましたが、これらの原理はドメイン設計において特に有用と思われます。 そこで、今回は分析・設計の流れとの関連を念頭に置きながら、これらの原理について概観します。

1. 設計/原理
2023年10⽉19⽇
浅海智晴
クラウドアプリケーションのための
オブジェクト指向分析設計講座
第28回
作業分野

2. SimpleModeling2021
• オブジェクト指向分析設計での共通範囲
• UML/UP
• 本講座で使⽤するUMLプロファイル
• プロファイル：SimpleModeling2021 (SM2021)
• オブジェクト指向分析設計の基本からの拡張部を明確化
• アジャイル開発
• Communication
• Embrace Change
• Travel Light
• Scaling
• Component-Based Development
• クラウド・アプリケーション
• モデル駆動開発
SM2021
Travel Light
Embrace Change
Cloud
Model-Driven
Scaling
CBD
Testability
Serviceability
• ⾮機能要件
• Testability
• Serviceability

3. 第1部 基本編の構成(1)
• 概論 [第1回]
• 開発プロセス [第2回]
• 基本モデル [第3回]
• 静的モデル(1) [第4回]
• 静的モデル(2) [第5回]
• 動的モデル [第6回]
• 協調モデル [第7回]
• 関数モデル [第8回]
• 物理モデル [第9回]
• 作業分野 [第10回]
• ビジネス・モデリング [第11回]
• 要求 [第12回]
• 要求/ユースケース [第13回]
• 要求/シナリオ [第14回]
• 分析 [第15回]
• 分析/コンポーネント分析 [第16回]
• 分析/イベント駆動 [第17回]
• 作業分野
• 設計 [第18回]
• 設計/アーキテクチャ設計 [第19回]
• 設計/コンポーネント設計(1) [第20回]
• 設計/コンポーネント設計(2) [第21回]
• 設計/コンポーネント設計(3) [第22回]
• 設計/ドメイン設計(1) [第23回]
• 設計/ドメイン設計(2) [第24回]
• 設計/ドメイン設計(3) [第25回]
• 設計/ドメイン設計(4) [第26回]
• 設計/ドメイン設計(5) [第27回]
• 設計/原理 [第28回]
• 設計/ UX/UI設計 [第29回]
• 実装 [第30回]
• テスト [第31回]

4. 第1部 基本編の構成(2)
• アプリケーション・アーキテクチャ [第32回]
• ドメイン・モデル [第33回]
• アプリケーション・モデル [第34回]
• プレゼンテーション・モデル [第35回]
• ケーススタディ[第36回]
• 要求モデル [第37回]
• 分析モデル [第38回]
• 設計モデル [第39回]
• 実装 [第40回]
• テスト [第41回]

5. 本講座のアプローチ
• オブジェクト指向分析設計の基本を確認
• UML + UP(Unified Process)
• CBD (Component-Based Development)
• 最新技術でアップデート
• クラウド・コンピューティング
• イベント駆動、分散・並列
• ビッグデータ、AI、IoT
• コンテナ
• 関数型
• OFP(Object-Functional Programming), Reactive Streams
• ルール, AI
• DevOps
• アジャイル開発
• DX (Digital Transformation)
第25回 アプリケーション・アーキテクチャ
第2回 開発プロセス
第9回 物理モデル
第11回 ビジネス・モデリング
第2部 クラウド・アプリケーション編
第21回 設計/ドメイン設計
第20回 設計/コンポーネント設計
第2部 クラウド・アプリケーション編

6. 原理 (Principle)
• Agile Software Development [ASD]
• SRP (The Single Responsibility Principle)
• OCP (The Open-Close Principle)
• LSP (The Liskov Substitution Principle)
• …
• GRASP (General Responsibility Assignment Software Patterns or principles)
• Low Coupling
• High Cohesion
• …
• Writing Effective Use Cases [WEUC]
• Scope
• …

7. パターン (Pattern)
• Design Patterns [DP]
• Observer, Strategy, …
• Domain Driven Design [DDD]
• Ubiquitous Language, Intention-
Revealing Interfaces, …
• Analysis Patterns [AP]
• Party, Quantity, …
• Pattern-Oriented Software
Architecture [POSA]
• Layers, Pipes and Filters, …
• Patterns of Enterprise
Application Architecture [PEAA]
• Unit of Work, Data Transfer Object,
…
• Enterprise Integration Patterns
[EIP]
• Message Bus, Aggregator, …
• Patterns for Effective Use
Cases [PEUC]
• CompleteSingleGoal,
VerbPhraseName, …
• AntiPatterns [AnP]
• Stovepipe System, Analysis
Paralysis, …

8. 内容
• 責務
• 原理
• GRASP
• Agile Software Development - 原理

9. 責務

10. 責務(Responsibility)
• クラスやその他の要素の契約(contract)または義務(obligation)
• ⾮公式な概念
• UML上はステレオタイプresponsibilityをつけたテキストで表現
• ユースケースからシナリオ分析でオブジェクトを抽出する際に、
シナリオから責務を抽出しオブジェクトに割り当てる
• コントロール・オブジェクト

11. 【⾷堂予約システム】ビジネス・ユースケース図 第11回 ビジネス・モデリング
再掲

12. SM2021
要求モデルとユースケース 第13回 要求/ユースケース
再掲

13. 第13回 要求/ユースケース
再掲

14. 【⾷堂予約システム】ユースケース図 第13回 要求/ユースケース
再掲

15. 【⾷堂予約システム】ユースケース図/ホール係、運営 第13回 要求/ユースケース
再掲

16. ロバストネス図 第16回 分析/コンポーネント分析
再掲

17. アプリケーション・ロジック
管理ロジック
利⽤者がリソースの更新を⾏うアプリケーションでは、
利⽤者管理、セッション管理が必要なので、この処理を
司るコンポーネントを追加
エンティティの格納・管理を⾏う
コンポーネント
イベント駆動アプリケーションで
イベントの発⽣、実⾏を司る
ジョブ実⾏やイベント駆動などの
バックグラウンド処理を⾏う
コンポーネント
コンポーネント・モデル
通知機能を司る
第16回 分析/コンポーネント分析
再掲

18. 原理

19. 書籍
• Agile Software Development [ASD]
• Agile Software Development, Principles, Patterns, and Practices
• アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技
• 2003, Robert C. Martin
• GRASP (General Responsibility Assignment Software
Patterns or principles)
• Applying UML and Patterns: An Introduction to Object-Oriented
Analysis and Design and Iterative Development (3rd)
• 実践UML 第3版 オブジェクト指向分析設計と反復型開発⼊⾨
• 2005, Craig Larman

20. キーワード
• 責務 (Responsibility)
• 疎結合 (Low Coupling)
• ⾼凝集 (High Cohesion)
• 再利⽤ (Reuse)

21. 疎結合と⾼凝集

22. 本講座のアプローチ
• 今回ご紹介する原理は疎結合を実現するために抽象(抽象クラス、
インタフェースなど)を導⼊するメカニズムが多い
• オブジェクト構造を設計する際の⼀般原則としてしまうと、⼿
間がかかりすぎて効率的ではない
• コンポーネント、サブシステムの設計時に適⽤を考えるとよい
• コンポーネント間
• 疎結合
• コンポーネント内
• 開発効率重視
CBD

23. GRASP

24. GRASP (General Responsibility Assignment
Software Patterns or principles)
• Applying UML and Patterns : An Introduction to Object-Oriented
Analysis and Design and Iterative Development (3rd)
• 実践UML 第3版 オブジェクト指向分析設計と反復型開発⼊⾨
• ⼀般的な責務割り当てソフトウェアのパターンと原則

25. GRASP
• Low Coupling (疎結合)
• High Cohesion (凝集)
• Information Expert (情報エキスパート)
• Creator (クリエーター)
• Controller (コントローラ)
• Polymorphism (ポリモーフィズム)
• Pure Fabrication (純粋な製造)
• Indirection (間接)
• Protected Variations (保護された変動)

26. Low Coupling (疎結合)
• 狙い
• 変更の衝撃を低減する
• (不必要な)結合が⼩さくなるように責務を割り当てる
• この原理は代替⼿段を評価するために⽤いる
• 複数の設計を⽐較する場合、同等機能であれば疎結合の⽅を採⽤する
とよい

27. High Cohesion (⾼凝集)
• 狙い
• オブジェクトを焦点があった、理解可能、管理可能な状態をキープ
• 副次的な効果として疎結合をサポート
• 凝集度が⾼くなるように責務を割り当てる
• 密接な関係を持つオブジェクト群を同じパッケージに配置する
• 効果
• 可読性、再利⽤性、保守性の向上
• この原理は代替⼿段を評価するために⽤いる
• 複数の設計を⽐較する場合、同等機能であれば疎結合の⽅を採⽤する
とよい

28. Information Expert (情報エキスパート)
• 狙い
• 汎⽤的な責務割当原理
• 情報エキスパート
• 責務を果たすために必要な情報を持っているクラス
• 責務は情報エキスパートに割り当てる

29. Creator (クリエーター)
• 狙い
• オブジェクトの作成に関する責務割当原理
• 以下の条件のいずれかが真である場合、クラスBにクラスAのイ
ンスタンスを作成する責任を割り当てる。
• BがAを含んでいる
• BがAを集約している
• BがAの初期データを持っている
• BがAを記録している
• BがAを密接に使⽤する
• 逆に⾔うと、オブジェクトの作成がプログラム全体に散逸する
ような構造は避ける

30. Controller (コントローラ)
• 狙い
• UI層とサービス層の責務割当原理
• UI層の裏側で、システム操作を受付け、協調動作するオブジェ
クトに責務を割り当てる
• ファサード・コントローラ
• システム全体を代表するオブジェクト
• ユースケース・コントローラ
• セッション・コントローラ
• ユースケース・シナリオを実⾏するオブジェクト

31. Polymorphism (ポリモーフィズム)
• 狙い
• 型ごとに振る舞いが異なる場合の責務割当
• 関連する代替や振る舞いが型(クラス)によって異なる場合、動
作が異なる型にポリモーフィックなオペレーションを使って、
振る舞いの責務を割り当てる。

32. Pure Fabrication (純粋な製造)
• 狙い
• 責務を割り当てる適切なクラスがない場合の責務割当
• ⾼凝集な責務群をドメインには存在しない概念の、⼈⼯的な扱
いやすい振る舞いクラスを新規に作成して、そこに割り当てる。
• 新クラスでは⾼凝集、疎結合、再利⽤を⼼がける

33. Indirection (間接)
• 狙い
• 直接結合を避けるための責務割当
• 他のコンポーネントやサービスの間で調停する中間オブジェク
トに責務を割り当て、それらが直接結合されないようにする。

34. Protected Variations (保護された変動)
• 狙い
• オブジェクト、サブシステム、システムといった要素の変動や不安定
性が他の要素に望ましくない影響を及ぼさないようにするための責務
割当
• 予測される変動や不安定性のポイントを特定し、それらの周り
に安定した「インターフェース」を作成するための責務を割り
当てる。

35. Agile Software
Development - 原理

36. Agile Software Development [ASD]
• Agile Software Development, Principles, Patterns, and Practices
• アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神
髄と匠の技
• SOLID
• オブジェクト間の基本原則
• パッケージングの原理
• オブジェクトを格納したパッケージ間の基本原則
• 本講座のアプローチではコンポーネントを基準に考えるとよい
CBD

37. SOLID
• The Single Responsibility Principle (SRP)
• The Open-Closed Principle (OCP)
• The Liskov Substitution Principle (LSP)
• The Interface Segregation Principle (ISP)
• The Dependency Inversion Principle (DIP)

38. LSP(Liskov Substitute principle)
• リスコフの置換原則
• 「サブタイプは⾃分のベースタイプと置き換え可能でなくては
ならない」
• クラスAのサブタイプB, C, Dはすべて、クラスAが定義したメ
ソッドを仕様どおり実現する必要がある
• 仕様通りの動作を担保する⽅法
• DbC(Design by Contract)
• ユニット・テスト

39. LSPの例

40. 悪い例

41. OCP(Open Close principle)
• 開放/閉鎖原則
• 拡張に対して開放(open)
• モジュールの振る舞いが拡張可能である。
• 修正に対して閉鎖(close)
• モジュールの振る舞いの拡張がモジュールのソース及びバイナリの変
更を引き起こさない。
OCP(Open close principle)は、以下の2種類が知られている
メイヤー版(1988)
マーチン版(1996)
本講座ではマーチン版を取り上げる

42. OCPの例

43. SRP(Single Responsibility principle)
• 単⼀責任の原則
• 「クラスを変更する理由は、ひとつだけであるべきである」
• モジュール、クラスまたは関数は、単⼀の機能について責任を
持ち、その機能をカプセル化するべき

44. SRPの例
X

45. ISP(Interface Segragation principle)
• インタフェース分離の原則
• 「使⽤しないメソッド群に依存することは強制されるべきでは
ない」
• ⼤きなインタフェースを機能ごとにメソッドを定義したインタ
フェース群に分離することを指向

46. ISPの例
X

47. DIP(Dependency Inversion principle)
• 依存性逆転原則
• 伝統的な依存関係
• 上位モジュールから下位モジュールへの依存性
• 依存性逆転原則
• 上位モジュールはいかなるものも下位モジュールから持ち込んではな
らない。双⽅とも抽象(例: インターフェース)に依存するべきである。
• 抽象は詳細に依存してはならない。詳細(具象的な実装内容)が抽象に
依存するべきである。
• 「抽象に依存せよ」
• UML : 要求インタフェース (required interface)

48. DIPの例
?

49. パッケージングの原理
• The Release-Reuse Principle (REP)
• The Common Closure Principle (CCP)
• The Common Reuse Principle (CRP)
• The Acyclic Dependencies Principle (ADP)
• The Stable Dependencies Principle (SDP)
• The Stable Abstractions Principle (SAP)

50. REP (Release-Reuse Equivalency principle)
• 再利⽤・リリース等価の原則
• 「再利⽤の単位はリリースの単位」
• パッケージ(モジュール、コンポーネント)を作成する際の指針
• パッケージは再利⽤とリリースに適した粒度にする
• パッケージが⼤きすぎると将来再利⽤の対象以外のクラスなどの進化
でパッケージが再利⽤できなくなるリスクが出てくる
• 「パッケージ内のすべてのクラスが再利⽤可能であるか、いずれも再
利⽤できないかのいずれかにする」
• 効果的な再利⽤は変更管理システムでのリリースの追跡が必要

51. CCP (Common Closure principle)
• 閉鎖性共通の原則/共通閉鎖原則
• ⼀緒に修正するクラスやモジュールは同じコンポーネントや
パッケージに⼀緒にパッケージするべき
• モジュール間の疎結合、⾼凝集を⽬指す
• 別名：Reuse/Release Equivalence Principle
• モジュール、コンポーネントの粒度は⼀緒に変更される可能性が⾼い
クラスを基準にするとよい

52. CRP (Common Reuse principle)
• 共通再利⽤原則
• パッケージ内のクラスは同時に再利⽤される。つまり、パッケージ
内の1つのクラスを再利⽤することは、パッケージに含まれた全ての
クラスを再利⽤することを意味する。
• 再利⽤の単位が異なるクラスは、同⼀のパッケージに含めるべきで
はない。
• 利⽤者: パッケージAのClassXを使う時に、パッケージBのClassBを
同時に使⽤するようになっている場合、パッケージBをほとんど使
わない利⽤者でも、パッケージAのバージョンアップに伴うパッ
ケージBの変更に追随してペッケージBのバージョンアップを⾏わな
ればならない、というようなことを避けたい

53. ADP (Acyclic Dependency principle)
• ⾮循環依存関係の原則
• パッケージ間の依存関係に循環があると:
• 1つのパッケージへの修正の影響が、循環するすべてのパッケージに及ぶ
• パッケージを単独でアップデートすることはできず循環するパッケージすべ
てを同時にアップデートする必要がある
• パッケージ分割されていても、事実上パッケージ分割されていないのと同じ
• パッケージをコンポーネントに読み替えるとよいかも
• 対策:
• DIP(依存関係逆転の法則)
• 新たなパッケージを導⼊する

54. SDP (Stable Dependency principle)
• 安定依存の原則
• 安定性の⽅向に依存する
• 安定性 (Stability)
• 変更の可能性の低さ
• ✘ 安定したパッケージから不安定なパッケージへの依存
• ○ 不安定なパッケージから安定したパッケージへの依存
• 安定したパッケージから不安定なパッケージ併存したい場合
• 抽象パッケージ(安定パッケージ)を中間に配置して解決する⽅法がある
I =
!"
!#$!"
Ca: パッケージに依存する外部クラス数
Ce: 外部パッケージに依存する内部クラス数

55. SAP (Stable-Abstractions principle)
• 安定抽象概念原則
• パッケージは安定しているだけでなく、抽象的であるべきであ
る
• 安定性が拡張性を損なわないため。
• 不安定なパッケージは、その不安定性が中に含まれる具体的なコード
を簡単に変更できるように、具体的であるべき
• 抽象度を計測
• メイン・シーケンス
A =
!"
!#
Nc: パッケージ内のクラス数
Na: パッケージ内の抽象クラス数
Dが⼤きいほどよい
[0, 1]
D’ = |A + I – 1|

56. まとめ
• 原理
• 責務、
• 疎結合、⾼凝集、
• 再利⽤
• GRASP
• 責務の割当原理
• 原理 [ASD]
• SOLID
• パッケージング

57. 参考⽂献
• The Unified Modeling Language Reference
Manual, 2nd (Rumbaugh他, 2004)
• The Unified Modeling Language User Guide,
2nd (Booch他, 2004)
• The Unified Software Development Process
(Jacobson他, 1999)
• The Object Constraint Language, 2nd (Warmer
他, 2003)
• UML 2 and the Unified Process: Practical
Object-Oriented Analysis and Design (Arlow
他, 2005)
• OMG Unified Modeling Language Version 2.5
(OMG, 2015)
• 上流⼯程UMLモデリング (浅海, 2008)
• Agile Software Development : Principles,
Patterns, and Practices (Martin他, 2003)
• Applying UML and Patterns : An Introduction
to Object-Oriented Analysis and Design and
Iterative Development, 3rd (Larman, 2005)

58. めも