MaruLaboの浅海ゼミでの講座のスライドです。 https://www.marulabo.net/docs/asami19/ 作業分野「設計」の最初の作業としてアーキテクチャ設計を説明します。 アーキテクチャ設計におけるコンポーネントを軸にした論理モデルと物理モデルの関係を軸に、 アーキテクチャ中心、原理、パターン、DevOpsについて取り上げます。

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

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

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

4. 本講座のアプローチ
• オブジェクト指向分析設計の基本を確認
• 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部 クラウド・アプリケーション編

5. 原理 (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 Principals)
• Low Coupling
• High Cohesion
• …
• Writing Effective Use Cases [WEUC]
• Scope
• …

6. パターン (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, …

7. 内容
• 実⾏基盤
• アーキテクチャ設計
• UML/UP
• 原理
• パターン
• DevOps
• アーキテクチャ・モデル
• 論理アーキテクチャ
• 物理アーキテクチャ

8. 実⾏基盤

9. 第9回 物理モデル
第18回 設計
第15回 分析

10. 実⾏基盤 (Foundation)
• 設計のターゲットとなる実⾏基盤を定める必要がある
• ⾮機能フィーチャのための基盤機能を提供
• コンポーネント組み⽴て/実⾏の基盤を提供
• アプリケーションを構成する各コンポーネントは実⾏基盤の提供す
る機能を前提に動作する
• 実⾏コンテキスト
• 実⾏基盤の構成要素
• OS、ミドルウェア、プログラミング⾔語
• アプリケーション・フレームワーク(Application Framework)
• ⾮機能フィーチャの詳細を吸収
• コンポーネント・フレームワーク(Component Framework)
• コンポーネントの組み⽴て基盤

11. 本講座の選択
• プログラミング⾔語
• Scala
• Javaエコシステム
• Pythonを併⽤
• コンテナ
• Docker/Kubernetes
• CI/CD
• Daggar
• ミドルウェア
• AWS
• クラウド・プラットフォーム
• AWS
• アプリケーション・フレームワーク
• 本講座が定義する仮想的なアプリケーション・フレームワーク
• コンポーネント・フレームワーク
• クラウド・アプリケーション
• 関数型

12. 実⾏コンテキスト (Execution Context)
• ある程度の複雑さを持ったアプリケーションはコンポーネント間で
共有する実⾏コンテキストが必要
• 実⾏コンテキスト
• データベース・トランザクション
• 認証
• 利⽤者情報
• 国際化
• 時間
• コンポーネントをどこまで疎結合できるかは実⾏コンテキストの共
有度にかかっている
• 実⾏コンテキストによってコンポーネント間で共有するリソース、
情報をカプセル化する

13. 実⾏コンテキスト

14. サブシステムのスタック

15. システム・アーキテクチャ

16. アーキテクチャ設計

17. アーキテクチャ設計
• アプリケーションのアーキテクチャを設計
• 分析で作成したアーキテクチャ・モデルを具体化する
• 実⾏基盤を選択
• ⾮機能フィーチャを具体化する
• 論理モデル
• サブシステム、コンポーネントを定義
• サブシステム、コンポーネントを組み⽴ててシステムを定義
• 物理モデル
• モジュールの組み⽴て、配備
第18回 設計

18. アーキテクチャ設計/新技術への対応
• クラウド・コンピューティング
• CQRS
• Event Sourcing
• マイクロサービス
• 関数
• ルール
• Reactive Streams
• DevOps
• Immutable Infrastructure/Infrastructure as a Code
第18回 設計
第2部 クラウド・アプリケーション編
第2部 クラウド・アプリケーション編
第8回 関数モデル
第25回 アプリケーション・アーキテクチャ
第21回 設計/ドメイン設計
第20回 設計/コンポーネント設計

19. アーキテクチャ設計のポイント
• UML/UP
• CBD (Component-Based Development)
• アーキテクチャ中⼼
• アーキテクチャ・ビュー
• アーキテクチャ・ベースライン
• 原理
• SOLID [ASD]
• Low Coupling/High Cohesion [GRASP]
• パターン
• Pattern-Oriented Software Architecture [POSA]
• Patterns of Enterprise Application Architecture [PEAA]
• Enterprise Integration Patterns [EIP]
• Domain Driven Design [DDD]
• DevOps

20. アーキテクチャ設計
UML/UP

21. アーキテクチャ (Architecture)
• ソフトウェア・システムの構成
• システムを構築する構成要素(コンポーネント、オブジェクト)
とそのインタフェース
• コンポーネント間の協調動作による振舞い
• 進化する⼤規模システムに落とし込むこれらの構造と振舞いの
構成
• この組織化をガイドするアーキテクチャ・スタイル
• 使⽤法、機能性、パフォーマンス、回復⼒、再利⽤、わかりや
すさ、経済性、技術的な制約とトレードオフ、美的関⼼といっ
たものも含む

22. アーキテクチャ中⼼ (Architecture Centric)
• ソフトウェア・アーキテクチャの初期開発とベースライン化に
フォーカス
• システムのアーキテクチャを主要な成果物とする
• 概念化、構築、管理、進化
• CBD (Component-Based Development)
• アーキテクチャ・ビュー (Architecture View)
• アーキテクチャ・ベースライン (Architectural Baseline)
• アーキテクチャの確⽴にフォーカスしたシステムの内部リリース(推敲
フェーズ)
第2回 開発プロセス

23. 第2回 開発プロセス
再掲
アーキテクチャ
ビュー

24. 第2回 開発プロセス
再掲
ユースケース→シナリオ分析→アーキテクチャ・ベースライン

25. 成果物 (Artifact)
• 外部ドキュメントや成果物な
どのソフトウェア開発プロセ
スによって、またはシステム
の展開と運⽤によって使⽤ま
たは⽣成される物理的な情報
の仕様。アーティファクトは、
モデル、説明、またはソフト
ウェアの場合がある。
第9回 物理モデル
再掲

26. ノード (Node)
• ノードは、計算リソースを表
す実⾏時の物理オブジェクト
であり、通常、少なくともメ
モリと多くの場合は処理機能
を備えている。ランタイム
アーティファクトはノードに
デプロイされる場合がある。
第9回 物理モデル
再掲

27. コンポーネント
(Component)
• システムデザインのモジュー
ル化された部品。外部インタ
フェースのセットで実装を隠
蔽する。システム内では同じ
インタフェースを満⾜してい
るコンポーネントは⾃由に取
り替えできる可能性がある。
第5回 静的モデル(2)
再掲
第9回 物理モデル
再掲

28. モジュール (Module)
• UMLのコンポーネントは元々、論理モデルの粒度＝物理モデルの粒
度という設定
• 実際の運⽤では論理モデルの粒度≠物理モデル粒度
• ⼀つのJARファイルに⼀つのコンポーネントしか実現できないのは⾮現実的
• コンポーネントは物理モデルを意識しつつも、論理モデルのモデル
として使⽤したい
• モジュールを導⼊
• コンポーネントを束ねた物理モデルを表現するモデル
• 1つのモジュールで複数のコンポーネントを束ねる
• Javaで実現する場合は、JAR、WARなどに相当
• Modules [DDD]
SM2021
第5回 静的モデル(2)
再掲
第9回 物理モデル
再掲

29. アーキテクチャ設計
原理

30. Agile Software Development [ASD]
• SOLID
• SRP (The Single Responsibility Principle)
• 単⼀責任の原則
• OCP (The Open-Close Principle)
• オープン/クロースドの原則
• LSP (The Liskov Substitution Principle)
• リスコフの置換原則
• ISP (The Interface Segregation Principle)
• インターフェース分離の原則
• DIP (Dependency Inversion Principle)
• 依存性逆転の原則

31. GRASP (General Responsibility Assignment
Software Patterns or Principals)
• Low Coupling
• 疎結合性
• High Cohesion
• ⾼凝集性
• Controller
• コントローラー
• Information Expert
• 情報を保持しているクラス(コンポーネント)に責務を割り当てる
• Pure Fabrication
• 「真っ⾚な嘘」。ドメイン・オブジェクトではなく⼈⼯的なクラス(コンポーネント)に責務を割り当てる
• Indirection
• 間接化
• Protected Variations
• バリエーション防護。クラス(コンポーネント)のバリエーションへの影響を受けない構造になっている

32. アーキテクチャ設計
パターン

33. アーキテクチャ・パターン
• Pattern-Oriented Software Architecture [POSA]
• 関連パターン
• Patterns of Enterprise Application Architecture [PEAA]
• アーキテクチャに関連するパターンも多数
• Enterprise Integration Patterns [EIP]
• Pipes & Filters [POSA] でのコンポーネントの接続パターン
• Domain Driven Design [DDD]
• Context、Large-Scale Structureの項にあるパターンが参考になる

34. Pattern-Oriented Software Architecture [POSA]
• 構造
• Layers
• Pipes & Filter
• Blackboard
• 分散システム
• Broker
• 対話システム
• Model-View-Control
• Presentation-Abstraction-Control
• 適⽤システム
• Microkernel
• Reflection

35. 三層アーキテクチャ

36. アーキテクチャ設計
DevOps

37. DevOps
• ソフトウェア開発(Dev)とITオペレーション(Ops)を結合するプラク
ティスの集まり。
• システム開発の短縮を⽬的とし⾼品質ソフトウェアの継続デリバ
リーを提供。
• 共同所有、ワークフロー・オートメーション、迅速なフィードバッ
ク
• 組織⽂化の変化まで視野に⼊るスケールの枠組み
• ツールの活⽤が前提
• Immutable Infrastructure
• CI/CD Pipeline
• IaC (Infrastructure as a Code)
• DevOps as a Service
第9回 物理モデル
再掲

38. CI/CD

39. モジュールの実現

40. アーキテクチャ・モデル

41. アーキテクチャ・モデル(分析) 第16回 分析/コンポーネント分析

42. アーキテクチャ・モデル
論理アーキテクチャ

43. 論理アーキテクチャ
• アーキテクチャ・ビュー
• 論理ビュー(設計ビュー)
• プロセス・ビュー(相互作⽤ビュー)

44. 論理ビュー
• 別名：設計ビュー
• コンポーネント図で論理的なアーキテクチャを定義
• 分析モデルのアーキテクチャ・モデルとほとんど同じ
• コンポーネントの粒度
• 最初期は分析モデルをそのまま流⽤できることが理想
• 分析段階でもある程度、設計を念頭に置いておくのが実務的
• 具体化を進めることで⼩さな差異がでてくるのでアーキテク
チャに反映

45. 分析モデルのアーキテクチャ・モデルを
そのまま設計モデルのアーキテクチャ・モデルに
アーキテクチャ・モデル(設計)

46. プロセス・ビュー
• 別名：相互作⽤ビュー
• システムの振舞いを詳細にモデル化
• 主にシステムの性能、スケーラビリティ、スループット、可⽤
性、回復性を扱う
• モデルの構成は基本的に論理ビュー(設計ビュー)と同じ

48. アーキテクチャ・モデル
物理アーキテクチャ

49. 物理アーキテクチャ
• アーキテクチャー・ビュー
• 実装ビュー
• 配備ビュー

50. 実装ビュー
• UMLの静的構造図(コンポーネント図)で成果物(artifact)を中⼼
に実装の構造を記述
• マニフェストで論理モデル(モジュール、コンポーネント)と接続
• 実務的には概要を⼀覧表にまとめておくので⼗分
• 図で記述する場合もUML以外の図でも問題ない

51. 実装ビュー/コンポーネント図

52. 配備ビュー
• 配備図を使って、ノードに配備する成果物を記述
• DevOpsの観点から、ビルドから配備まで⾃動化でいる部分と
できない部分を明確にしておく

53. 配備図 (Deployment Diagram) 第9回 物理モデル
再掲

54. まとめ
• 分析モデルのアーキテクチャ・モデルから設計モデルのアーキ
テクチャ・モデルを作成
• アーキテクチャ・ビュー
• ユースケース・ビュー
• 論理ビュー、プロセス・ビュー、実装ビュー、配備ビュー
• 原理、パターンを活⽤する
• DevOpsを包含したモデリングを⾏う

55. 参考⽂献
• 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)
• Pattern-Oriented Software Architecture: A
System of Patterns (Buschamnn他, 1996)
• Patterns of Enterprise Application Architecture
(Fowler他, 2002)
• Enterprise Integration Patterns: Designing,
Building, and Deploying Messaging Solutions
(Hohpe他)
• Domain-Driven Design: Tracking Complexity
in the Heart of Software (Evans, 2003)