非機能要求からア非機能要求からア キテクチャーキテクチャへ · 2020. 7....
TRANSCRIPT
SoftwareEngineering 非機能要求とシステム設計
~安全・安心なCPS構築に向けて~
Information-technology Promotion Agency, JapanCenter 安全 安心なCPS構築に向けて
非機能要求からアーキテクチャへ非機能要求からア キテクチャ~アーキテクチャの意思決定に影響するNFRの見極め~
大嶽 隆児
エンタプライズ系プロジェクト非機能要求とアーキテクチャ分析WG
年 月 平安2011年2月3日 14:10-14:50 平安
1Software Engineering CenterSoftware Japan 2011
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
講師略歴
1980年新潟大学農学部(森林計測学)卒業.1981年日本IBM入社.IBM入社.
1980年代に分散システム開発のSEを担当.1990年代にオリンピックプロジェクトのITアーキテクトを担当 2000年オリンピックプロジェクトのITアーキテクトを担当.2000年代にe-businessプロジェクトのリードアーキテクト,および
既存システムのアーキテクチャ分析・評価 グローバル,既存システムのア キテクチャ分析・評価,グロ バル企業のEA、BPM駆動SOA開発メソドロジー等を担当.
IBM A d f T h l 会員 IBM Di ti i h dIBM Academy of Technology会員.IBM Distinguished Engineer.
The Open Group ITAC Distinguished Certified IT Architect.
Software Engineering Center 2Software Japan 2011Software Japan 2011
IPA/SEC非機能要求とアーキテクチャ分析WG委員.Copyright © 2010-2011 IPA, All Rights Reserved
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
概要
高品質ITシステムを短期間構築するニーズにより,成功事例や参照アーキテクチャ(RA)を活用するITアーキテクトが増えている.
成功事例を一般化したRAには,機能要求だけでなく,様々な非機能要求(NFR)の対立関係を全体最適で解決するアーキテクチャの基本パタ が複合的 含くまれ る基本パターンが複合的に含くまれている.
そのため,NFRの対立関係,NFRと基本パターンの因果関係,前提条件などRAの本質を理解せずに 安易に真似てITシステムを設提条件などRAの本質を理解せずに,安易に真似てITシステムを設計すると,前提条件が異なる場面や環境では全体最適のバランスが崩れ 期待したNFRを満足しないリスクがあるが崩れ,期待したNFRを満足しないリスクがある.
本講演では,IPA/SECのNFRとアーキテクチャWGで実施したRAの事例研究の紹介とアーキテクチャの意思決定に影響するNFRの見事例研究の紹介とア キテクチャの意思決定に影響する の見極めを考察してみる.
Software Engineering Center 3Software Japan 2011Software Japan 2011 Copyright © 2010-2011 IPA, All Rights Reserved
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
アジェンダ
1. アーキテクチャ決定に影響するNFRの見極め成功事例や参照アーキテクチャ(RA)を参考にして、個別システムのアーキテクチャを策定する場合、NFRの対立関係、NFRとアーキテクチャの因果関係、前提条件、仮説など、を理解することが重要になる
非機能要求からアーキテクチャを策定する過程を追いながら アーキテクチ非機能要求からア キテクチャを策定する過程を追いながら、ア キテクチャ決定に影響するNFRを見極め、必要性に対する正当性と理論的根拠を明らかにする方法を紹介する
参照 キ ク ( ) 事例 究 紹介2. 参照アーキテクチャ(RA)の事例研究の紹介インターネットに公開されているPatterns for e-business (以下、P4eb) を研究材料として 複数のアプリケーション・パターンに含まれる基本パターンと究材料として、 複数のアプリケ ション パタ ンに含まれる基本パタ ンとNFRの関係、ステークホルダー要求、ドライバー/モチベーションまで因果関係の解読を試みた。
複数のアプリケ シ ン パタ ンの違いを決定づけている基本パタ ンと品質複数のアプリケーション・パターンの違いを決定づけている基本パターンと品質要求や制約を識別する
アプリケーション・パターン選択の動機づけになっているドライバー(ビジネス要求と 要求)と基本パタ ンの間にある複雑な因果関係を可視化する
Software Engineering Center 4Software Japan 2011Software Japan 2011
とIT要求)と基本パターンの間にある複雑な因果関係を可視化する
Copyright © 2010-2011 IPA, All Rights Reserved
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
1. アーキテクチャ決定に影響するNFRの見極め
非機能要求からアーキテクチャを策定する過程を追いながら、アーキテクチャ決定に影響するNFRを見極め、必要性に対する正当性と理論的根拠を明らかにする方法を紹介する
非機能要求からアーキテクチャへ
品質要求から技術的な機能要求へ変換
構造と振る舞いで解決するNFRの見極め
アーキテクチャ決定過程の4つの重要な分析
アーキテクチャの正当性と理論的根拠
決定にはポリシーとプリンシプルが重要
Software Engineering Center 5Software Japan 2011Software Japan 2011 Copyright © 2010-2011 IPA, All Rights Reserved
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
非機能要求からアーキテクチャへ
ステークホルダー要求 業務部門 IT部門経営層外部成功事例/参照アーキテクチャ
開発するITシステムの要求
非機能要求
品質要求
その他の要求
機能要求 業務部門の人間系プロセス
品質要求
制約機能分解
関連するITシステム
機能割り当て 開発・テストプロセス
移行プロセスアーキテクチャ要求構成要素
ソフトウェア(機能)
アプリケ シ ン
アーキテクチャ
静的構造
展開プロセス
教育プロセスアプリケーション
技術機能動的振る舞い
ITサ ビ 管理プ セ
保守プロセス
教育プロセス
Software Engineering Center 6Software Japan 2011Software Japan 2011
ハードウェア(資源) 能力・資源割り当てITサービス管理プロセス
Copyright © 2010-2011 IPA, All Rights Reserved
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
品質要求から技術的な機能要求へ変換
品質要求は、技術的な機能要求に変換して、アーキテクチャの構成要素に割り当てる
非機能 求非機能要求
品質要求非機能要求の品質要求
性能 応答が速い性能 応答が速い
性能 応答が速い
セキュリティ 攻撃に強い
可用性 回復が早い
技術的な機能要求
・・・・ 成功事例/参照アーキテクチャ
技術的な機能要求動的なページをリバースプロキシにキャッシュする、
パイプ・アンド・フィルタでウイルス検出する、
構成要素
技術機能パイプ アンド フィルタでウイルス検出する、
HAクラスターで自動的にテークオーバーする、
・・・
技術機能動的なページをキャッシュする
Software Engineering Center 7Software Japan 2011Software Japan 2011 Copyright © 2010-2011 IPA, All Rights Reserved
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
構造と振る舞いで解決するNFRの見極め
NFRには、構成要素に割り当てた機能要求だけでは実現できず、システムの静的な構造や動的な振舞いで解決するアーキテクチャ要求(ASR : Architecturally Significant Requirements) がある
成功事例/参照ア キテクチャ
機能要求 システム
キ ク
アーキテクチャ要求
参照アーキテクチャ
=+アーキテクチャ
静的構造
振 舞
デカルトの還元主義(R d ti i )
アリストテレスの全体論
動的振る舞い
(Reductionism)「複雑な物事をその構成要素に分解し、個別の構成要素の総体により複雑な全体の性質や振る舞いも
(Holism)「全体とは、部分の総和以上の
「何か」である」
Software Engineering Center 8Software Japan 2011Software Japan 2011
出典 : SARA(Software Architecture Review and Assessment Report) Version 1.0
http://philippe.kruchten.com/architecture/SARAv1.pdf
り複雑な全体の性質や振る舞いも全て理解できる」
Copyright © 2010-2011 IPA, All Rights Reserved
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
アーキテクチャ決定過程の4つの重要な分析
ドライバー/モチベーション(動機づけ)
ゴール リスク全体 適 局所 適
リスクのあるシナリオユースケースミスユースケースフ イルケ ス
ステークホルダー
要求
場面(新規出店、事業統廃合、海外展開など)
フェイルケースチェンジケース・・など
品質リスクあり
成功事例/参照アーキテクチャ
非機能要求
品質要求
非機能要求分析
リスク分析 アーキテクチャ決定
品質リスクあり
制約 トレードオフ分析決定
品質リスクなしシステム状況
アーキテクチャ決定理由
運転モード正常、縮退、制限、代替
状況通常時、サージ(予想可能なピーク)、バースト(予
測不可能なピーク
アーキテクチャ
静的構造
アーキテクチャ分析
センシティビティ分析
決定理由「品質リスクなし」
とした前提と仮説
Software Engineering Center 9Software Japan 2011
動的振る舞い コンフリクト分析
前提と仮説
Copyright © 2010-2011 IPA, All Rights Reserved
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
アーキテクチャの正当性と理論的根拠
アーキテクトは、決定したアーキテクチャが解決するNFRの正当性(Justification)、および、NFRが満たされる理論的根拠(Rationale)、および、それらの前提条件と仮説に対して、説明責任(Accountability)がある
ドライバー/モチベーション正当性
正当性の根拠
正当性Justification
ITシステムの品質
ゴール リスク
必要性の根拠
ステークホルダー要求ITシステムの品質を良くすると、ビジネスのゴールの達成またはリスク
理論的根拠Rationale
非機能要求
品質要求 制約
達成またはリスクの緩和・回避に貢
献する
アーキテクチャには、ITシステムの品質が良くなる静的
理論的根拠必要性の根拠
アーキテクチャ
質が良くなる静的構造や動的振る舞
いの仕掛け(Mechanism)と原理
Software Engineering Center 10Software Japan 2011Software Japan 2011
静的構造 動的振る舞い
( ) 原(Principle)がある
Copyright © 2010-2011 IPA, All Rights Reserved
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
決定にはポリシーとプリンシプルが重要
ドライバー/モチベーション(動機づけ)
ゴール リスク全体 適 局所 適ステーク
ホルダ 要求ビジネス要求
ステークホルダー要求
業務部門 IT部門経営層外部
ホルダー要求正当性根拠
非機能要求
ビジネス・ポリシー(行動指針)ビジネス要求
優先順位
非機能要求分析
ガイディング・プリンシプル(基本原則)
業務部門 IT部門
非機能要求機
経営層外部 非機能要求必要性
IT
IT要求優先順位
非機能要求分析
トレ ドオフ分析
リスク分析
非機能要求
品質要求
制約
機能要求 ア キテクチャ
ITシステ
アーキテクチャ・プリンシプル(原理/定石)
トレードオフ分析制約求
アーキテクチャ
アーキテクチャ必要性
テム
ASR
アーキテクチャ
静的構造
アーキテクチャ分析
センシティビティ分析
機能仕
アーキテクチャ理論的根拠IT
シス
Software Engineering Center 11Software Japan 2011Software Japan 2011
コンフリクト分析
仕様 動的振る舞い
テム
Copyright © 2010-2011 IPA, All Rights Reserved
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
2. 参照アーキテクチャ(RA)の事例研究の紹介
インターネットに公開されているPatterns for e-business (以下、P4eb) を研究材料として、 複数のアプリケーション・パターンに含まれる基本パターン(注)とNFRの関係、ステークホルダー要求、ドライバー/モチベーションまで因果関係の解読を試みた。
複数のアプリケ シ ン パタ ンの違いを決定づけている基本パタ ンと品複数のアプリケーション・パターンの違いを決定づけている基本パターンと品質要求や制約を識別する
アプリケーション・パターン選択の動機づけになっているドライバー(ビジネスリ 選択 動機 ラ (要求とIT要求)と基本パターンの間にある複雑な因果関係を可視化する
参照:連載:ソフトウエアパターンの世界第2回 アーキテクチャーパターンとは何か参照: Patterns for e-business
注) 基本パターンとは、「アーキテクチャパターンに含まれている主目的の品質を良くするアーキテクチャの仕掛けや基本要素である 」
羽生田 栄一http://thinkit.co.jp/article/940/1
https://www.ibm.com/developerworks/patterns/
ーキテクチャの仕掛けや基本要素である。」アーキテクチャの仕掛け(Architectural Mechanism) [Len Bass]
品質属性設計の基本要素(Quality Attribute Design Primitive)[Len Bass]
アーキテクチャの基本要素(Architectural Primitive)[Uwe Zdun]
Software Engineering Center 12Software Japan 2011Software Japan 2011
参照: Len Bass et al., Technical Note CMU/SEI-2000-TN-007Uwe Zdun at al., Modeling Architectural Patterns Using Architectural Primitives, OOPSLA ’05, October 2005
ア キテクチャの基本要素(Architectural Primitive)[Uwe Zdun]
Copyright © 2010-2011 IPA, All Rights Reserved
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
Patterns for e-businessの分析
ビジネスとITのドライバー(動機づけ)からアプリケーション・パターンを選択するデシジョンテーブルだけでは、基本パターンとNFRの関係や必要性に対する正当性や理論的根拠が曖昧である。
ビジネス・ドライバー スタンドアロン
シングルチャネル
ルーター エージェント
迅速なビジネス開始 ○
複数のデリバリー・チャネルの ○ ○複数のデリ リ チャネルの統合
○ ○
顧客から見たビューの統一 ○顧客から見たビュ の統 ○
一括カスタマイズ ○
Software Engineering Center 13Software Japan 2011Software Japan 2011
注) セルフサービスから3つのアプリケーション・パターンについて、一部のビジネス・ドライバーだけを引用している。
Copyright © 2010-2011 IPA, All Rights Reserved
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
セルフサービスのアプリケーション・パターン分析
e-businessセルフサービスの3つアプリケーション・パターンに含まれる基本パターンとNFRの関係を分析した。
①スタンドアロンシングルチ ネル
新しいチャネル向けのセルフサービスを短期かつ低コストで開発する。技術変化が早いプレゼン論
更新
凡例
利点
ホスト端末
①スタンドアロンシングルチャネル
同期 適時性アプリケーション
2 既存アプリとは業務連携
技術変化が早いプレゼン論理層(ティア)をアプリ論理層から分離する。
新規
一時的
参照
プレゼン論理層からの1つの要求を1つのアプリ論理層にル ルに基づ
保守性
ができない。プレゼンテーション1
同期 アプリケーション1
既存
端末
②ルーター1つのアプリ論理層にルールに基づき転送する。
アプリケーションが停止すると
セルフサービスができない。
保 性
アプリケーション2
プレゼンテーション2
プ ゼ シルーター
同期 同期最新性
③エージェント
ODSに注文データを登録した後、事後に非同期でアプリ論理層に手配ができる。事前に非同期でアプリ論理層か
プレゼンテーション1
アプリケーション1
ル タ
ルール 同期
③エ ジェント 事前に非同期でアプリ論理層から処理結果を取得し在庫や商品情報を更新できる。1つの要求を複数のアプリ論理層に分割・集約できる
プレゼンテーション2
プレゼンテーション
アプリケーション2
アプリケーションエージェント
同期 非同期可用性
Software Engineering Center 14Software Japan 2011Software Japan 2011
層に分割・集約できる。
アプリケーションが停止してもセルフサービスができる。
1ア リケ シ
1ODS 同期非同期
Copyright © 2010-2011 IPA, All Rights Reserved
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
識別した基本パターンとNFRの関係
品質属性の「○○性」だけでは、因果関係が曖昧になる基本パターン タイプ 品質 青: メリット 赤: デメリット 黒: 制約
(括弧) 明記されていない
スタンドアロ
ルーター
エージェ(括弧) 明記されていない ドアロ
ンター ジェ
ント
アプリ層とプレゼン層の分離
静的構造 保守性: UIの要求や技術の変化に迅速に対応する Y Y Y
直接接続 静的構造 (時間効率性: 処理パス長が短く応答時間が早い)
(制約: 機関、コスト、体制など)
Y N N
ハブ・アンド・スポー 静的構造 保守性: インタフェースの多様性や変化に迅速 N Y Yク接続 に対応する
更新データ(ODS)のハブ配置
(アプリ層のハブ配置)
静的構造 可用性: 既存アプリのサービス時間帯や計画停止の制約下でも24x365に対応する
新性: ODSとマスタ デ タ間に遅延がある
- N Y
(アプリ層のハブ配置) 新性: ODSとマスターデータ間に遅延がある
プレゼン層の同期統合 動的振舞 (使用性: 応答の有無が直ぐに判る)
(制約: スキル/非同期は設計が難しい)
Y Y Y
プ ゼ 層の非同期統 動的振舞 使用性 遅 処理結果の応答を待たな N Yプレゼン層の非同期統合
動的振舞 使用性: 遅い処理結果の応答を待たない
資源効率性: 資源を占有しない
- N Y
アプリ層の同期統合 動的振舞 (時間効率性: 処理パス長が短く応答時間が早い)
( 新性: マスタ 更新デ タにアクセスできる)
- Y Y
Software Engineering Center 15Software Japan 2011Software Japan 2011
( 新性: マスター更新データにアクセスできる)
アプリ層の非同期統合 動的振舞 「更新データ(ODS)のハブ配置」と同じ - N Y
Copyright © 2010-2011 IPA, All Rights Reserved
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
基本パターン、NFR、ドライバーの因果関係
パターン記述から抽出した因果関係(目的-手段、原因-結果)をメタモデルにまとめた・・・が。
ドライバー
ビジネス IT
目的→手段原因→結果(効果・影響)
非機能要求
品質要求
原因 結果(効果 影響)
品質要求
制約
基本パタ ンアーキテクチャ
Software Engineering Center 16Software Japan 2011Software Japan 2011
基本パターンパターン
Copyright © 2010-2011 IPA, All Rights Reserved
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
ドライバーと基本パターンの間の複雑な因果関係
識別した基本パターンからドライバー(動機づけ)までの複雑な因果関係の分析を試みた・・・が。
Software Engineering Center 17Software Japan 2011Software Japan 2011 Copyright © 2010-2011 IPA, All Rights Reserved
SECSoftware Engineeringfor Mo・No・Zu・Ku・Ri
まとめ
決定したアーキテクチャからビジネスのゴール達成までの因果関係は、「風が吹くと桶屋が儲かる」になっており、正当性と理論的根拠を説明することが非常に難しい拠を説明することが非常に難しいアーキテクチャ決定の主要な動機づけは、既存IT制約(接続先、共有基盤、再利用サービスなど)、プロジェクト制約(期間、コスト、体制
スキルなど)制約 および これらの制約に起因するITシステムの、スキルなど)制約、および、これらの制約に起因するITシステムの品質リスク緩和・回避であるアーキテクトは、NFRとアーキテクチャに関して、ビジネス・リスクへの影響とその正当性と理論的根拠に関して、アーキテクチャ決定理由に前提条件や仮説を明記し、プロジェクトの上流工程で、仮説検証するタスクを計画するべきである
「品質不足 「過剰品質検証するタ クを計画する ある
リスク : 低い品質により失われるビジネス上の価値
「品質不足」 .vs 「過剰品質」
リスク : 低い品質により失われるビジネス上の価値
Software Engineering Center 18Software Japan 2011Software Japan 2011
ゴール : 高い品質により達成するビジネス上の価値
Copyright © 2010-2011 IPA, All Rights Reserved