シリーズ記事の目次
システムアーキテクチャ設計の高度なスキル ・ソフトウェアアーキテクチャの概念、アーキテクチャスタイル、ABSD、アーキテクチャ再利用、DSSA (1) 【システムアーキテクト】 システムアーキテクチャ設計の高度なスキル ・システムの品質属性とアーキテクチャ評価 (2) 【
システムアーキテクト
】システムアーキテクチャ設計・ソフトウェア信頼性解析・設計(3) 【システムアーキテクチャ設計者】
现在的一切都是为将来的梦想编织翅膀，让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.
システムアーキテクチャ設計・システム品質特性とアーキテクチャ評価 (2)
1. ソフトウェアシステムの品質属性の考え方 ★★★
1.1 開発期間における品質特性
開発期間中の品質属性は、次のサブ属性に分類されます。
| 属性 | 説明する |
|---|---|
| わかりやすさ | デザイン開発者による理解しやすさを指します。 |
| スケーラビリティ | 新しい要件の変化に適応して新しい機能を追加するソフトウェアの能力は、柔軟性とも呼ばれます。 |
| 再利用性 | ソフトウェア システムまたは特定の部品の再利用の容易さを指します。 |
| テスト容易性 | ソフトウェアが要件仕様を満たしていることを実証するためのソフトウェアのテストが容易になります。 |
| 保守性 | 不具合の修正、機能の追加、品質の向上が必要な場合、修正点の特定と実装の容易さ。 |
| 携帯性 | ソフトウェア システムを 1 つのオペレーティング環境から別のオペレーティング環境に簡単に移動できること。 |
1.2 実行時の品質属性
実行時品質属性は、次のサブ属性に分割されます。
| 属性 | 説明する |
|---|---|
| パフォーマンス | ソフトウェア システムは、速度、スループット、容量などの対応するサービス機能をタイムリーに提供します。 |
| 安全性 | ソフトウェア システムは、正規のユーザーにサービスを提供し、不正使用を防止する機能を考慮しています。 |
| スケーラビリティ | ユーザー数やデータ量が増加した場合でも、高いサービス品質を維持できるソフトウェア システムの能力。 |
| 相互運用性 | ソフトウェア システムが他のシステムとデータを交換したり、サービスを呼び出したりできる容易さ。 |
| 信頼性 | ソフトウェア システムが一定期間問題なく動作し続ける能力。 |
| 可用性 | 一定期間内でシステムが正常に動作する時間の割合。 |
| 堅牢性 | 異常な状況（ユーザーによる不正な操作、関連するソフトウェアおよびハードウェア システムの障害）下でもソフトウェア システムが正常に動作する能力は、堅牢性またはフォールト トレランスとも呼ばれます。 |
2. アーキテクチャ評価の品質属性
アーキテクチャの評価プロセス中、評価者はシステムの品質特性に焦点を当てます。
2.1 パフォーマンス
パフォーマンスとは、システムの応答性、つまり、イベントへの応答にかかる時間、またはシステムが一定期間内に処理できるイベントの数を指します。
例えば：
- 同時に 1000 人の同時ユーザーをサポート
- 応答時間は1秒未満
- ディスプレイ解像度は4Kに達します
パフォーマンスを向上させるための戦略 (パフォーマンス戦術) は、次の側面から検討できます。
- リソース要件:
① コンピューティング効率の向上、② コンピューティングのオーバーヘッドの削減、③ イベント レートの管理 (処理されるイベント数の削減)、④ サンプリング周波数の制御 (リソースの使用の制御) - リソース管理:
①同時実行メカニズムの導入、②複数のコピーの維持、③利用可能なリソースの増加 - リソース調停:
リソース スケジューリング戦略: ① 先入れ先出し、② 固定優先度、③ 動的優先度、④ 静的デバッグ
2.3 可用性
可用性とは、システムが正常に動作できる時間の割合です。多くの場合、障害間の時間の長さ、または障害が発生した場合にシステムがどれだけ早く通常の状態に戻ることができるかという観点で表現されます。
例えば：
- メインサーバーに障害が発生した場合、1分以内にバックアップサーバーに切り替わります。
- システム障害、1時間以内に修復
- 7×24時間勤務をサポートするシステムです
可用性を向上させるための戦略 (可用性戦術) は、次の側面から検討できます。
- エラー検出：
①コマンド/レスポンス[Ping/Echo]、②ハートビート、③異常 - エラー回復:
①投票、②冗長性[アクティブ/パッシブ]、③バックアップ[再同期、内部テスト、チェックポイント/ロールバック] - エラー回避：
①プロセス監視、②トランザクション、③サーバーから削除【サービスオフライン】
2.4 セキュリティ
セキュリティとは、正規のユーザーにサービスを提供しながら、権限のないユーザーによるサービスの使用または拒否を防止するシステムの機能を指します。セキュリティは、機密性、完全性、否認防止、制御性などの特性に分類できます。
例えば：
- SQLインジェクション攻撃に対する耐性
- コンピュータ操作は完全に記録されます (ログ、監査証跡)
- ユーザー情報データベースの認証では 99.9% の可用性を確保する必要があります
セキュリティを向上させるための戦略（セキュリティ戦術）は、次のような側面から考えることができます。
- 攻撃への抵抗:
① ユーザー認証、② ユーザー認可、③ データの機密性と完全性の維持、④ 公開の制限、⑤ アクセスの制限 - 攻撃の検知：
①侵入システムの検知 - 攻撃からの回復：
①攻撃者の特定：監査証跡、②回復状態：冗長性［可用性と重複］
2.3 変更可能性
変更可能性とは、高いパフォーマンスと価格の比率でシステムに迅速に変更を加える能力を指します。修正可能性は通常、特定の変更に基づいて、これらの変更のコストを調査することによって測定されます。
例えば：
- システム レポート モジュールへの変更は 2 人週間以内に完了する必要があります
- Web インターフェースのスタイルを変更します。変更は 4 人月以内に完了する必要があります。
変更可能性は 4 つのサブ属性に分類されます。
保守性: ローカル修復により、アーキテクチャに対する障害の悪影響が最小限に抑えられます。
スケーラビリティ: 疎結合により、アーキテクチャに影響を与えることなく新しい機能を実装することが容易になります。
構造の再編成: 本体の柔軟な構成には影響しません。
移植性: さまざまな環境 (ハードウェア プラットフォーム、言語、オペレーティング システムなど) に適用できます。
パフォーマンスを向上させるための戦略 (変更可能な行戦術) は、次の側面から検討できます。
- 局所的な変更:
① 高い凝集性と低い結合性、② 変更の予測、③ モジュールの汎用化、④ モジュールの一般化、⑤ セマンティックな一貫性の維持、⑥ 可能な選択肢の制限、⑦ 共通サービスの抽象化 - 連鎖反応を防ぐ：
①情報を隠す、②既存のインターフェースを維持する、③通信経路を制限する、④アービターを利用する - バインディング時間の延期:
① ランタイム登録、② 設定ファイル、③ ポリモーフィズム、④ コンポーネントの置換、⑤ 定義されたプロトコルの遵守
2.4 使いやすさ
ユーザビリティは、ユーザーが目的のタスクを完了するのがいかに簡単か、およびシステムが提供するユーザー サポートの種類に焦点を当てます。
例えば：
- フレンドリーなインターフェース
- 新しいユーザーがシステムの使用方法を習得するのに 2 時間もかかりません。
2.5 テスト容易性
ソフトウェアのテスト容易性とは、テストを通じてソフトウェアの欠陥を明らかにする容易さを指します。
例えば：
- リモート デバッグ インターフェイスを提供し、リモート デバッグをサポートします
2.6 信頼性
2 つのサブ属性に分けられます。
フォールト トレランス: エラーが発生した後もシステムの実行が保証され、エラーは独自に修正できます。
堅牢性: エラーはシステムに影響を与えず、確立された手順に従ってエラーは無視されます。
2.7 機能
ニーズの満足度。
2.8 変動性
全体的なアーキテクチャは可変です。
2.9 相互運用性
視覚化またはインターフェイスを通じて、より優れたインタラクティブな操作エクスペリエンスを提供します。
3. 品質属性のシナリオの説明
品質属性シナリオは、刺激源、刺激、環境、製品、応答、および応答測定で構成される特定の品質属性の要件です。
(1) ソース: 刺激を生成するエンティティ (人間、コンピュータ システム、またはその他の刺激装置)。
(2) 刺激: 刺激がシステムに到達するときに考慮する必要がある条件を指します。
(3) 環境: 特定の条件下で発生する刺激を指します。励起が発生すると、システムは過負荷、動作、またはその他の状態にある可能性があります。
(4) 成果物: 成果物は動機付けられており、システム全体またはシステムの一部である場合があります。
(5) 反応：刺激が届いた後にとられる行動を指します。
(6) 応答測定: 応答が発生した場合、要件をテストするために何らかの方法で測定する必要があります。
4. システムアーキテクチャの評価
アーキテクチャ評価のベンチマークは、アーキテクチャの品質特性です。
4.1 システムアーキテクチャ評価における重要な概念
4.1.1 センシティブポイント、トレードオフポイント、リスクポイント、および非リスクポイント
感度ポイント: 1 つ以上のコンポーネント (および/またはコンポーネント間の関係) の特性。
トレードオフポイント: 複数の品質属性に影響を与える特性であり、複数の品質属性の敏感な点です。
リスクポイント: アーキテクチャ設計における潜在的かつ問題のあるアーキテクチャ上の決定によって引き起こされる隠れた危険を指します。
ノンリスクポイント（Non-Risk Point）：隠れた危険を引き起こさないことを意味し、一般的には「○○要件は実現できる（または受け入れられる）」という形で表現されます。
例えば：
- トランザクションリクエストの処理時間の要件は、システムのデータ送信プロトコルと処理プロセスの設計に影響します（センシティブポイント）。
- 1秒あたりのユーザートランザクションリクエスト数が10、リクエスト処理時間が30ミリ秒であると仮定すると、「ユーザーのトランザクションリクエストを1秒以内に完了する」という要件は達成可能です（非リスクポイント）
- 現時点では、システムのクレジットカード決済のビジネスロジックの記述について合意が得られておらず、一部の業務機能モジュールが重複し、システムの修正可能性に影響を与える可能性（リスクポイント）がある。
- 暗号化レベルを変更すると、セキュリティとパフォーマンスに影響が生じます(トレードオフ ポイント)
4.1.2 リスク保有者または関連する利害関係者
アーキテクチャに影響を与える、またはアーキテクチャによって影響を受けるグループ。
4.1.3 シナリオ
アーキテクチャの品質評価目標を決定するための対話型メカニズムは、通常、トリガー メカニズム (刺激)、環境、影響の 3 つの側面から考慮されます。
4.2 システムアーキテクチャの評価方法
アーキテクチャの評価方法は、一般に次の 3 つのカテゴリに分類されます。
-
アンケートやチェックリストによる評価方法は、
関係者を組織して評価を行う方法であり、最もシンプルで実施しやすい方法ですが、非常に主観的です。 -
メトリックベースの評価方法は、
定量的な指標を重視し、最も客観的な方法ですが、評価者がシステムに精通している必要があり、そうでないとさまざまな指標を数値化することが困難であるため、この方法は実装が困難です。 -
シナリオベース評価手法は、
システムの重要なシナリオを選別し、さまざまなシナリオでのパフォーマンスに基づいてシステムを評価する手法であり、客観性は両者の中間に位置する手法であり、現在広く普及している構造評価手法でもあります。
シーンベースの主な方法は3 つあります(最初の 2 つの方法がより一般的に使用されます)。
- ソフトウェアアーキテクチャ分析手法（SAAM、ソフトウェアアーキテクチャ分析手法）
- アーキテクチャトレードオフ分析手法 (ATAM)
- 費用便益分析手法 (CBAM、費用便益分析手法)
4.2.1 シナリオベースのソフトウェアアーキテクチャ分析手法SAAM
SAAM は当初、アーキテクチャの変更可能性を分析するために使用され、後に他の品質属性にも拡張されました。
SAAM の分析および評価アーキテクチャのプロセスは、以下に示す 5 つのステップで構成されます。
(1)シナリオ開発
(2)アーキテクチャの説明
(3)単一シナリオの評価
(4)シナリオ相互作用の評価
(5)全体の評価
4.2.2 シナリオベースのアーキテクチャトレードオフ分析手法 ATAM
アーキテクチャ トレードオフ分析手法 (ATAM、アーキテクチャ トレードオフ分析手法) は、SAAM 上で開発されました。中心となるのは、品質属性ユーティリティ ツリーに基づいてシステムを評価し、リスク ポイント、敏感なポイント、トレードオフ ポイントを決定し、システム アーキテクチャに関する決定と妥協を行うことです。評価プロセス全体では、性能、実用性、安全性、変更可能性を中心とした品質特性が評価の核として重視されており、これらの品質特性はシステム開発前に評価され、妥協されます。
ATAM は以下に示すように 4 つの段階に分かれています。
(1)シナリオと要件の収集
(2)アーキテクチャ ビューとシナリオの実装
(3)品質モデルの構築と分析
(4)品質モデルの妥協
4.2.3 品質属性ユーティリティツリー
品質属性ユーティリティ ツリー: 主にパフォーマンス、可用性、変更可能性、セキュリティの 4 つの側面を含む品質属性を識別および分類します。
パフォーマンス: パフォーマンスの遅延 (ユーザー データベースの保存を最小 300 ミリ秒まで遅延させ、リアルタイムのビデオ画像を提供します)、トランザクション スループット (認証サーバーの平均スループットを最大化します)。
修正可能性：製品カタログの追加、商用製品の修正（CORBAミドルウェア追加の作業量は20人月未満、Webインターフェース変更の作業量は4人月未満）。
可用性: ハードウェア障害 (サイト A の電源が失われた場合、タスクは 3 秒以内にサイト B にリダイレクトされる必要があります。ディスクに障害が発生した場合は 5 分以内に再起動する必要があり、ネットワーク障害は 1- 以内に検出され、復元される必要があります) 5分）、商用ソフトウェアの障害。
セキュリティ: データの機密性 (クレジット カード取引は 99.999% の確率で安全であり、顧客データベースの Z 認証は 99.999% の確率で機能します)、データの整合性。
品質属性ユーティリティ ツリーの図の例は次のとおりです。
