ソフトウェアパターン概論およびパターンを活用したアーキテクチャ設計
•
0 likes•1,982 views
鷲崎弘宜, "ソフトウェアパターン概論およびパターンを活用したアーキテクチャ設計", スマートエスイーセミナー: IoT・機械学習応用ソフトウェアの設計とパターン, 2020/07/13
Recommended
More Related Content
What's hot
What's hot (20)
Similar to ソフトウェアパターン概論およびパターンを活用したアーキテクチャ設計
Similar to ソフトウェアパターン概論およびパターンを活用したアーキテクチャ設計 (20)
More from Hironori Washizaki
More from Hironori Washizaki (20)
ソフトウェアパターン概論およびパターンを活用したアーキテクチャ設計
- 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
- 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 刺激源 成果物 環境 刺激 応答 応答測定法実現手法 アーキテクチャパタ ーン/スタイル
- 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
- 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.