1. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
1
セミナー: IoT・機械学習応用ソフトウェアの設計とパターン
ソフトウェアパターン概論およびパ
ターンを活用したアーキテクチャ設計
鷲崎 弘宜
早稲田大学ほか
IEEE Computer Society 2021-2023 Board of
Governors 候補者
2020年 7月13日
v20200713

2. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
目次
◼ パターン（ランゲージ）とソフトウェアパターン
◼ アーキテクチャ設計
◼ アーキテクチャ評価
2

3. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
パターン（ランゲージ）とソフトウェア
3

4. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
4
https://en.wikipedia.org/wiki/Coffeehouse#/media/File:Caf%C3%A9_de_Flore.jpg
https://ja.wikipedia.org/wiki/%E3%82%AB%E3%83%95%E3%82%A7#/media/%E3%83%95%E3%82
%A1%E3%82%A4%E3%83%AB:Former_Foreign_Settlement_of_Kobe_Hyogo_Japan_A55_03s3.jpg
名前: 路上カフェ
解決: 各近隣にカフェが開かれるよう促すこと。カフェにはいくつかの部屋を設け、
にぎやかな歩行路に向けて解放し、座ってコーヒーなどの飲み物を取りながら、
移りゆく世界を眺められるような親しみのある場所に仕立てること。カフェの前面
は、室内からテーブル・セットが街路にそのまま張り出すような作りとすること。
問題: 忙しい都会において、衆目の中で合法
的に腰を下ろし、移りゆく世界をノンビリと眺め
られる場所がほしい。
[Alexander77] C. Alexander他著, 平田翰那訳, “パタン・ランゲージ”, 鹿島出版, 1977

5. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
5
建築におけるパターンランゲージ
◼ 粒度をまたいだ繋がり
◼ 街の中心部には 活動の拠点 として 小さな広
場 を設けよう。その広場には、訪問者や近隣
の人々が気軽に集い落ち着けるように、いくつ
かの 路上のカフェ が集まってひらかれるよう
に奨励しよう。それぞれのカフェは、オープン
エアで楽しめるように 街路への開口 を持たせ
られるとよい ・・・
◼ 同一粒度における繋がり
◼ 快適に暮らせるためには 屋内の陽光 は不可
欠なので、 南向きの屋外 に庭をおきたいな。
さらに、部屋の陽光をたくさんとって快適にす
るために どの部屋も二面採光 にしたい。そう
そう、お客さんにも来てほしいから、 街路への
開口 をもうけて、玄関から寝室までうまく 親
密度の変化 をもたせたいね ・・・
玄関
居間
寝室
庭
建物 口
街
路
街路
広場
カフェ

6. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
6
class Mathematic {
public Data sort(Data data){
switch(settings) {
case QUICK:
return quickSort(data);
case BUBBLE:
return bubbleSort(data);
default: ...
}
}
class Loan {
public double capital() {
if(expiry == null &&
maturity != null)
return ...;
if(expiry != null &&
maturity == null) {
...
}
class Mathematic {
Sorter sorter;
public Data sort(Data data){
return sorter.sort(data);
}
abstract class Sorter {
public abstract Data sort(Data);
class QuickSorter extends Sorter {
public Data sort(Data) { ... }
class Loan {
CapitalCalc capitalCalc;
public double capital(){
return capitalCalc.calc(this);
}
Interface CapitalCalc {
double calc(Loan l);
class TermCapital implements ...{
double calc(Loan l) { ... }

7. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
例: オブジェクト指向デザインパターン Strategy
Context Strategy
algorithmInterface()
ConcreteStrategyA
algorithmInterface()
ConcreteStrategyB
algorithmInterface()
・・・
・・・
contextInterface()
解決
同期（文脈）
If there are hard-wiring line breaking algorithms, clients get
bigger and harder to maintain. Moreover it becomes difficult to
add new algorithms and vary existing ones…
適用可能性（問題、フォース）
Many related classes differ only in their behavior.
You need different variants of an algorithm…
結果
利点: families of algorithms , elimination of conditional statements…
欠点: Communication overhead…
E. Gamma, et al. “Design Patterns: Elements of Reusable Object-
Oriented Software,” Addison-Wesley, 1994.
7

8. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
8
パターンランゲージとソフトウェア
◼ ソフトウェアコミュニティが学んだこと
◼ 文脈（Know-Why）、問題（What）、解決（How）の言語化・文書化形式
◼ 抽象的なビジョンと、具体的なライブラリ・指示の間の抽象度
◼ 対話の手段、問題・解決の再利用、非機能要求満足とアーキテクチャ一貫
◼ 特にソフトウェア設計、開発プロセス・組織構造
◼ ソフトウェアコミュニティが（あまり）学ばなかったこと [羽生田]
◼ 利害関係者間の合意形成のための共通言語
◼ 利用者参加型の仕組み、生成的
成功事例
文脈: こういうときに
問題: こうしたかったら・こう困っていたら
フォース: こういうことを考慮して
解決: こうしなさい
結果: こうなるでしょう
新たな状況
解決 解決
抽象化 具象化
類似
抽象化
羽生田栄一 監修, パターンワーキンググループ著, "ソフトウェアパターン入門～基礎から応用へ～", ソフトリサーチセンター, 2005.

9. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
パターン、参照アーキテクチャ、実現手法
◼ アーキテクチャパターン、デザインパターン
◼ 典型的な優れたアーキテクチャや詳細設計の導出過程をパターン化
◼ アーキテクチャスタイル: Batch Sequentialパターン, Repositoryパターン,
Interpreterパターンなど [Shaw]
◼ POSAアーキテクチャパターン: Layersパターン,
MVCパターン, Pipes and Filtersパターンなど [POSA]
◼ デザインパターン: GoFデザインパターンなど
◼ 参照アーキテクチャ: 特定ドメインのためのテンプレート
◼ 実現手法: 特定品質を満足する実装技術、パターン、設計原則
9
再利用して効率的かつ効果的にアーキテクチャ設計
一部: 鄭顕志,”アーキテクチャ・品質エンジニアリング”, スマートエスイー, 2018
[Shaw] M. Shaw & D. Garlan, "Software Architecture: Perspectives on an Emerging Discipline", Prentice Hall, 1996
[POSA] F. Buschmann and et.al., “Pattern-Oriented Software Architecture, A System of Patterns: Volume 1 (Wiley
Software Patterns Series)”, Wiley, 2013
刺激源
成果物
環境
刺激 応答
応答測定法実現手法
アーキテクチャパタ
ーン/スタイル

10. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
アーキテクチャ設計
10

11. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
アーキテクチャとは
◼ システムの基本的な概念や性質 [ISO/IEC/IEEE 42010]
◼ 構成要素、要素間の関係、設計・進化の原則から成る
◼ 効果:理解、再利用、構築、進化、分析、管理 [Garlan14]
◼ AI/ML・IoTシステムにおける必要性
◼ 大規模化／複雑化に伴い、途中で変更することが困難
◼ 非機能要求（信頼性／性能／拡張性などの向上）の増大
◼ 多種多様な技術、環境、サービスの組み合わせの意思決定
11
実装要求
設計 実装
実装・進化
達成 準拠
達成
アーキテクチャ
図: CMU SEI, Software Architecture, http://www.sei.cmu.edu/architecture
図: 鄭顕志,”アーキテクチャ・品質エンジニアリング”, スマートエスイー, 2018

12. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
例: Netflixのアーキテクチャ 12
Browser
(Smart)
TV
Mobile/Table
t
Gaming
Console
Media-
Player
Load Balancer
(Amazon ELB)
WebAPIGatewa
y
Streaming
Control API
Cassandra
Cluster
AmazonS3
AmazonSQ
S
Playback
UserProfile
DRM
Review
Search
Notifications
Video History
Recommendatio
n
…
Edge
Services
Backend
Services
Mid-tire
Services
IaaS
Services
HTTP request
REST aync.
REST aync.
Platform
Services
ServiceRegistry
Security,Monitoring,Configuration,
Logging,Rx,Dynamicrouting,Caching,…
図: Stefan Toth, An Inverse Evaluation of Netflix Architecture Using ATAM, SATURN2016
図: 鄭顕志,”アーキテクチャ・品質エンジニアリング”, スマートエスイー, 2018

13. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
アーキテクチャの種類と課題
◼ システム、基盤アーキテクチャ（物理層）
◼ 主に非機能要求の実現
◼ 品質目標の曖昧な構築 ⇒ 非機能要求駆動の設計、評価
◼ アプリケーションアーキテクチャ（論理層）
◼ 主に機能要求の実現
◼ 一貫性の欠如、保守の難しさ ⇒ 原則やパターン等に基
づく一貫した設計、評価
13
ソフトウェア
ハードウェア
アプリケーション
基盤
システム
参考: 長谷川, アーキテクチャ設計評価, 日科技連SQIP研究会演習, 2017

14. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
設計上のアーキテクチャドライバ
（主たる要求）
◼ 主機能
◼ 品質（シナリオ）
◼ 制約: 技術、組織、顧客
◼ システムの種類: 新システム（
ドメイン未知、既知）、既存シ
ステム変更
◼ 設計目的: プロトタイプ、顧客
用、連続的進化
◼ 関心事: その他の設計上必要
な決定
14
アーキテクチャ
ドライバ
アーキテクチャ
設計
アーキテクチャ
アーキテクチャ
パターン/スタイル
実現手法参照アーキテ
クチャ
一部: 鄭顕志,”アーキテクチャ・品質エンジニアリング”, スマートエスイー, 2018

15. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
アーキテクチャ設計手法
Attribute-Driven Design (ADD)
◼ カーネギーメロン大学(CMU) Software Engineering
Institute(SEI)で開発
◼ 要求を優先順位付けし，各イテレーションごとに扱う要求
を実現するようにアーキテクチャを段階的に洗練化
◼ 設計の検討の際には参照アーキテクチャ，アーキテクチ
ャスタイル等の過去の優れた知見を参考に
15
ユーザー
System
要求1
優先順位
高 低
ユーザー ユーザー
1st
Iteration
2nd
Iteration
要求2 要求4要求3 要求5
鄭顕志,”アーキテクチャ・品質エンジニアリング”, スマートエスイー, 2018
L. Bass, et al. 前田ほか訳: 実践ソフトウェアアーキテクチャ（Software Architecture in
Practice 2nd Ed.）, 日刊工業新聞社, 2005

16. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
IoT事例: 疲労予測・改善 16
身体行動データ
視線・まばたきデータ
生
成
予
測
疲労度
推
薦
改善行動JINS MEME
(メガネ型センサー)
鄭顕志,”アーキテクチャ・品質エンジニアリング”, スマートエスイー, 2018
◼ 機能要求
◼ FR1:計測を開始する
◼ FR2:疲労度を表示する
◼ 品質要求
◼ QR1(変更容易性): 新規ユーザ追加容易
◼ QR2(変更容易性): データ処理方式の追加容易
◼ QR3(可用性): 接続が一時切断しても・・・
◼ 制約
◼ C1: 推定モデルは専門チームによって事前に構
築
◼ C2: 推定モデルの実行時更新は現段階では扱
わない
FR1 FR2
QR1 QR2
QR3
FR3
優先順位
高
低
優先順位付けられた要求
C1 C2

17. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
1回目: 基本的な要求に着目 17
FR1:計測を
開始する
FR2:疲労度
を表示する
考慮する要求 適用パターン
Actions
Insights
Things
IoT参照アーキテクチャ
HealthCareU
I
MEMEData
Processing
MEMEData
Collector
ユーザー MEME
Stress
Estimator
Insights Things
MEMEデータからのストレス度推定
にはDLで構築する回帰モデルを使用
1. sendData(data)
1.1 estimate(data)
1.2 show(stress)
データを生成するThings
生成されたデータに基づき
分析するInsights
C1:推定モデ
ルの制約
C2:推定モデル
更新の制約
改善行動推薦などの機能
は対象ではないため
Actionsは省略
鄭顕志,”アーキテクチャ・品質エンジニアリング”, スマートエスイー, 2018

18. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
2回目: 変更容易性に着目 18
鄭顕志,”アーキテクチャ・品質エンジニアリング”, スマートエスイー, 2018
QR1(変更容易性
): MEMEの追加
QR2(変更容易性):
データ処理の追加
考慮する要求 適用パターン
/実装技術
Publish-Subscribe
Health
CareU
I
MEMEData
Processing
MEMEData
Collector
ユーザー MEME
Stress
Estimator
Insights Things
2. publish(data, topic)
2.1.1 estimate(data)
2.1.2 show(stress)
Broker
<<publisher>>
1. subscribe(topic)
2.1. notify(data, topic)
<<subscriber>> <<broker>>
デバイスID等をtopicとして
必要とするデータ処理
(subscriber)にのみ通知
Brokerを介した疎結合のため
デバイス追加時は個別のデータ処
理部に変更は必要なし
データ処理部追加時もBroker
のみに依存．データ生成部に
変更は必要なし
Publisher
Broker
Subscriber
Publisher
Subscriber

19. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
アーキテクチャ評価
19

20. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
アーキテクチャの評価
◼ 定量的評価: 測定による How much
◼ ゴール指向、結果の解釈は難しい。
◼ チェックリストや原則に照らした評価
◼ 定性的評価
◼ シナリオによる What if
◼ あらゆる注目する品質特性に集中できるが, 精度は評価者の経験に
依存
◼ 手法: Architecture Tradeoff Analysis Method (ATAM)など
20
CMU/SEI, The Architecture Tradeoff Analysis Method (ATAM),
http://www.sei.cmu.edu/architecture/ata_method.html
＋－多層（レイヤ）
－＋コントロールループ
・・・セキュリティシナリオ信頼性シナリオアーキテクチャ

21. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
Architecture Trade-off
Analysis Method (ATAM)
◼ CMU/SEIが提唱するアーキテクチャ設計手法
◼ 設計上の判断/選択/決定が品質要求を十分に扱うかを評価
◼ 品質特性を予測する試みではない
◼ 比較的軽量: 通常3日程度で実施
◼ 目的
◼ リスクの発見: 品質特性について将来問題を生じる可能性のあ
る選択肢、トレードオフポイント（およびセンシティビティポイント）
はリスクの候補
◼ センシティビティーポイントの発見: 僅かな変化が品質特性に有
意な差をもたらす選択肢
◼ トレードオフポイントの発見: 複数の品質特性に影響する決定
◼ 事例多数: 米ボーイング, Netflix[Toth]
21
Stefan Toth, An Inverse Evaluation of Netflix Architecture Using ATAM, SATURN2016

22. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
センシティビティ＆トレードオフポイント
22
⇒通信の暗号化 セキュリティ
の向上
性能の
低下
&
マスター キャッシュ アプリケーション
ファイルサーバ アプリケーションサーバ
暗号化
⇒キャッシュ 実行効率
の向上
資源効率
の低下
&
ただし「書き込み率」が大きいと
ヒットしなくなり逆に性能を損なう
Michel Chaudron, Software Architecting, http://www.win.tue.nl/~mchaudro/swads/

23. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
まとめ
◼ パターンによるKnow-Why/What/Howの言語化と再利用
◼ 共通言語としてのパターンランゲージへ
◼ IoT・AI時代のアーキテクチャの重要性：異種技術、多種多
様な選択や組み合わせ
◼ 品質に駆動されるアーキテクチャの設計と評価、パターン
や実現手法の参照活用
◼ アーキテクチャ設計・評価の詳細やコツは、ぜひ「スマート
エスイー」で学びましょう！
23

24. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae
enPit-Proスマートエスイーのご紹介 https://smartse.jp
◼ 文科省 社会人教育 enPiT-Pro AI・IoT×ビジネス
◼ 履修証明プログラム10科目120時間
◼ 一部JMOOCオンライン提供中、関連内容をセミナー
24
全国規模の14大学・
研究所ネットワーク
26以上の企業・業界
団体(会員企業5000
超)・自治体との連携
+
+
クラウド
センサ・IoT
人工
知能
ビッグ
データ 生成
知識
抽出
革新
情報処理
アプリケーション
ビジネス
価値
創造
題材・事例
教材・指導
受講生派遣・
外部評価
進学・共同
研究接続
教材・指導
地区展開
スマートエスイー
通信・物理協力校

25. 質問 http://sli.do/ #58755
アンケートhttp://u0u1.net/Urae 25
参考: より深めるために
◼ パターンの原典をあたる
◼ C. Alexander他著, 平田翰那訳, “パタン・ランゲージ”, 鹿島出版,
1977
◼ ソフトウェアパターンの広がり全体を掴む
◼ 深澤監修, 鷲崎, 丸山, 山本, 久保, “ソフトウェアパターン”, 近代科
学社, 2007.
◼ 羽生田栄一 監修, パターンワーキンググループ著, "ソフトウェアパ
ターン入門～基礎から応用へ～", ソフトリサーチセンター, 2005.
◼ ソフトウェアパターンとパターンランゲージの最先端を知る
◼ 鷲崎, 江渡, 吉岡, 位野木, 本橋, 羽生田, 懸田, 井庭, “ソフトウェア
パターン － 時を超えるソフトウェアの道", 情報処理, 情報処理学会,
Vol.52, No.9, 2011.