非機能要求からア非機能要求からアキテクチャーキテクチャへ · 2020. 7. 1. · 参照キク参照アーキテクチャ()(ra)の事例究紹介事例研究の紹介

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


概要

高品質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


アジェンダ

1. アーキテクチャ決定に影響するNFRの見極め成功事例や参照アーキテクチャ(RA)を参考にして、個別システムのアーキテクチャを策定する場合、NFRの対立関係、NFRとアーキテクチャの因果関係、前提条件、仮説など、を理解することが重要になる

非機能要求からアーキテクチャを策定する過程を追いながらアーキテクチ非機能要求からアキテクチャを策定する過程を追いながら、アキテクチャ決定に影響するNFRを見極め、必要性に対する正当性と理論的根拠を明らかにする方法を紹介する

参照キク ( ) 事例究紹介2. 参照アーキテクチャ(RA)の事例研究の紹介インターネットに公開されているPatterns for e-business (以下、P4eb) を研究材料として複数のアプリケーション・パターンに含まれる基本パターンと究材料として、複数のアプリケションパタンに含まれる基本パタンとNFRの関係、ステークホルダー要求、ドライバー/モチベーションまで因果関係の解読を試みた。

複数のアプリケシンパタンの違いを決定づけている基本パタンと品質複数のアプリケーション・パターンの違いを決定づけている基本パターンと品質要求や制約を識別する

アプリケーション・パターン選択の動機づけになっているドライバー(ビジネス要求と要求)と基本パタンの間にある複雑な因果関係を可視化する


とIT要求)と基本パターンの間にある複雑な因果関係を可視化する

Copyright © 2010-2011 IPA, All Rights Reserved


1. アーキテクチャ決定に影響するNFRの見極め

非機能要求からアーキテクチャを策定する過程を追いながら、アーキテクチャ決定に影響するNFRを見極め、必要性に対する正当性と理論的根拠を明らかにする方法を紹介する

非機能要求からアーキテクチャへ

品質要求から技術的な機能要求へ変換

構造と振る舞いで解決するNFRの見極め

アーキテクチャ決定過程の4つの重要な分析

アーキテクチャの正当性と理論的根拠

決定にはポリシーとプリンシプルが重要



非機能要求からアーキテクチャへ

ステークホルダー要求業務部門 IT部門経営層外部成功事例/参照アーキテクチャ

開発するITシステムの要求

非機能要求

品質要求

その他の要求

機能要求業務部門の人間系プロセス

品質要求

制約機能分解

関連するITシステム

機能割り当て開発・テストプロセス

移行プロセスアーキテクチャ要求構成要素

ソフトウェア(機能)

アプリケシン

アーキテクチャ

静的構造

展開プロセス

教育プロセスアプリケーション

技術機能動的振る舞い

ITサビ管理プセ

保守プロセス

教育プロセス


ハードウェア(資源) 能力・資源割り当てITサービス管理プロセス



品質要求から技術的な機能要求へ変換

品質要求は、技術的な機能要求に変換して、アーキテクチャの構成要素に割り当てる

非機能求非機能要求

品質要求非機能要求の品質要求

性能応答が速い性能応答が速い

性能応答が速い

セキュリティ攻撃に強い

可用性回復が早い

技術的な機能要求

・・・・成功事例/参照アーキテクチャ

技術的な機能要求動的なページをリバースプロキシにキャッシュする、

パイプ・アンド・フィルタでウイルス検出する、

構成要素

技術機能パイプアンドフィルタでウイルス検出する、

HAクラスターで自動的にテークオーバーする、

・・・

技術機能動的なページをキャッシュする



構造と振る舞いで解決するNFRの見極め

NFRには、構成要素に割り当てた機能要求だけでは実現できず、システムの静的な構造や動的な振舞いで解決するアーキテクチャ要求(ASR : Architecturally Significant Requirements) がある

成功事例/参照アキテクチャ

機能要求システム

キク

アーキテクチャ要求

参照アーキテクチャ

=+アーキテクチャ

静的構造

振舞

デカルトの還元主義（R d ti i ）

アリストテレスの全体論

動的振る舞い

（Reductionism）「複雑な物事をその構成要素に分解し、個別の構成要素の総体により複雑な全体の性質や振る舞いも

(Holism)「全体とは、部分の総和以上の

「何か」である」


出典： SARA(Software Architecture Review and Assessment Report) Version 1.0

http://philippe.kruchten.com/architecture/SARAv1.pdf

り複雑な全体の性質や振る舞いも全て理解できる」



アーキテクチャ決定過程の4つの重要な分析

ドライバー/モチベーション(動機づけ)

ゴールリスク全体適局所適

リスクのあるシナリオユースケースミスユースケースフイルケス

ステークホルダー

要求

場面(新規出店、事業統廃合、海外展開など)

フェイルケースチェンジケース・・など

品質リスクあり

成功事例/参照アーキテクチャ

非機能要求

品質要求

非機能要求分析

リスク分析アーキテクチャ決定

品質リスクあり

制約トレードオフ分析決定

品質リスクなしシステム状況

アーキテクチャ決定理由

運転モード正常、縮退、制限、代替

状況通常時、サージ（予想可能なピーク）、バースト（予

測不可能なピーク


静的構造

アーキテクチャ分析

センシティビティ分析

決定理由「品質リスクなし」

とした前提と仮説

Software Engineering Center 9Software Japan 2011

動的振る舞いコンフリクト分析

前提と仮説



アーキテクチャの正当性と理論的根拠

アーキテクトは、決定したアーキテクチャが解決するNFRの正当性(Justification)、および、NFRが満たされる理論的根拠(Rationale)、および、それらの前提条件と仮説に対して、説明責任(Accountability)がある

ドライバー/モチベーション正当性

正当性の根拠

正当性Justification

ITシステムの品質

ゴールリスク

必要性の根拠

ステークホルダー要求ITシステムの品質を良くすると、ビジネスのゴールの達成またはリスク

理論的根拠Rationale

非機能要求

品質要求制約

達成またはリスクの緩和・回避に貢

献する

アーキテクチャには、ITシステムの品質が良くなる静的

理論的根拠必要性の根拠


質が良くなる静的構造や動的振る舞

いの仕掛け(Mechanism)と原理


静的構造動的振る舞い

( ) 原(Principle)がある



決定にはポリシーとプリンシプルが重要

ドライバー/モチベーション(動機づけ)

ゴールリスク全体適局所適ステーク

ホルダ要求ビジネス要求

ステークホルダー要求

業務部門 IT部門経営層外部

ホルダー要求正当性根拠

非機能要求

ビジネス・ポリシー(行動指針)ビジネス要求

優先順位


ガイディング・プリンシプル(基本原則)

業務部門 IT部門

非機能要求機

経営層外部非機能要求必要性

IT

IT要求優先順位


トレドオフ分析

リスク分析

非機能要求

品質要求

制約

機能要求アキテクチャ

ITシステ

アーキテクチャ・プリンシプル(原理/定石)

トレードオフ分析制約求


アーキテクチャ必要性

テム

ASR


静的構造

アーキテクチャ分析

センシティビティ分析

機能仕

アーキテクチャ理論的根拠IT

シス


コンフリクト分析

仕様動的振る舞い

テム



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]


参照: 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]



Patterns for e-businessの分析

ビジネスとITのドライバー(動機づけ)からアプリケーション・パターンを選択するデシジョンテーブルだけでは、基本パターンとNFRの関係や必要性に対する正当性や理論的根拠が曖昧である。

ビジネス・ドライバースタンドアロン

シングルチャネル

ルーターエージェント

迅速なビジネス開始 ○

複数のデリバリー・チャネルの ○ ○複数のデリリチャネルの統合

○ ○

顧客から見たビューの統一 ○顧客から見たビュの統 ○

一括カスタマイズ ○


注) セルフサービスから3つのアプリケーション・パターンについて、一部のビジネス・ドライバーだけを引用している。



セルフサービスのアプリケーション・パターン分析

e-businessセルフサービスの3つアプリケーション・パターンに含まれる基本パターンとNFRの関係を分析した。

①スタンドアロンシングルチネル

新しいチャネル向けのセルフサービスを短期かつ低コストで開発する。技術変化が早いプレゼン論

更新

凡例

利点

ホスト端末

①スタンドアロンシングルチャネル

同期適時性アプリケーション

２既存アプリとは業務連携

技術変化が早いプレゼン論理層(ティア)をアプリ論理層から分離する。

新規

一時的

参照

プレゼン論理層からの1つの要求を1つのアプリ論理層にルルに基づ

保守性

ができない。プレゼンテーション１

同期アプリケーション１

既存

端末

②ルーター1つのアプリ論理層にルールに基づき転送する。

アプリケーションが停止すると

セルフサービスができない。

保性

アプリケーション２

プレゼンテーション２

プゼシルーター

同期同期最新性

③エージェント

ODSに注文データを登録した後、事後に非同期でアプリ論理層に手配ができる。事前に非同期でアプリ論理層か

プレゼンテーション１

アプリケーション１

ルタ

ルール同期

③エジェント事前に非同期でアプリ論理層から処理結果を取得し在庫や商品情報を更新できる。1つの要求を複数のアプリ論理層に分割・集約できる

プレゼンテーション２

プレゼンテーション

アプリケーション２

アプリケーションエージェント

同期非同期可用性


層に分割・集約できる。

アプリケーションが停止してもセルフサービスができる。

１アリケシ

１ODS 同期非同期



識別した基本パターンと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


( 新性: マスター更新データにアクセスできる)

アプリ層の非同期統合動的振舞「更新データ(ODS)のハブ配置」と同じ - N Y



基本パターン、NFR、ドライバーの因果関係

パターン記述から抽出した因果関係(目的-手段、原因-結果)をメタモデルにまとめた・・・が。

ドライバー

ビジネス IT

目的→手段原因→結果(効果・影響)

非機能要求

品質要求

原因結果(効果影響)

品質要求

制約

基本パタンアーキテクチャ


基本パターンパターン



ドライバーと基本パターンの間の複雑な因果関係

識別した基本パターンからドライバー(動機づけ)までの複雑な因果関係の分析を試みた・・・が。



まとめ

決定したアーキテクチャからビジネスのゴール達成までの因果関係は、「風が吹くと桶屋が儲かる」になっており、正当性と理論的根拠を説明することが非常に難しい拠を説明することが非常に難しいアーキテクチャ決定の主要な動機づけは、既存IT制約(接続先、共有基盤、再利用サービスなど)、プロジェクト制約(期間、コスト、体制

スキルなど)制約およびこれらの制約に起因するITシステムの、スキルなど)制約、および、これらの制約に起因するITシステムの品質リスク緩和・回避であるアーキテクトは、NFRとアーキテクチャに関して、ビジネス・リスクへの影響とその正当性と理論的根拠に関して、アーキテクチャ決定理由に前提条件や仮説を明記し、プロジェクトの上流工程で、仮説検証するタスクを計画するべきである

「品質不足「過剰品質検証するタクを計画するある

リスク : 低い品質により失われるビジネス上の価値

「品質不足」 .vs 「過剰品質」

リスク : 低い品質により失われるビジネス上の価値


ゴール : 高い品質により達成するビジネス上の価値


非機能要求からア非機能要求からア キテクチャーキテクチャへ · 2020. 7. 1. · 参照 キ ク参照アーキテクチャ()(ra)の事例究紹介事例研究の紹介

Documents

非機能要求からア非機能要求からアキテクチャーキテクチャへ · 2020. 7. 1. · 参照キク参照アーキテクチャ()(ra)の事例究紹介事例研究の紹介