P57 4章 アーキテクチャ特性

言葉の定義

P57 4章 アーキテクチャ特性 より

 アーキテクチャ特性とは、問題領域とは独立した、システムの重要な側面だ。
 ソフトウェアのそうした特徴を非機能要件と呼ぶ組織も多い。
 しかし、非機能要件という用語は否定表現だ。
 そのため、著者らはその表現を好まない。
(中略)
 よく使われる別の用語に、品質特性がある。
 しかし、著者らはこの表現も好まない。
 この用語だと、設計よりも事後に行う品質評価の印象が強いと感じるからだ。
 私たちが好んで使うのは、アークてくちゃ特性という用語だ。
 なぜなら、この用語が、アーキテクチャやシステム全体の静甲に不可欠な関心事を、その重要性を損なうことなく表していると考えるからだ。

まさしく同じ様な印象をこれら用語に感じていた。
私もアーキテクチャ特性という用語を推していきたいと思った。

アーキテクチャ特性とは

P58 4章 アーキテクチャ特性 より

  • ドメインに依らない、設計に関する考慮事項を明らかにするもの
  • 設計の構造的な側面に影響を与えるもの
  • アプリケーションの静甲に不可欠か重要なもの

アーキテクチャ特性リスト

運用特性
  • 可用性(Availability)
  • 継続性(Continuity)
  • パフォーマンス(Performance)
  • 回復性(Revoverability)
  • 信頼性/安全性(Reliability/Safety)
  • 堅牢性(Robustness)
  • スケーラビリティ(Scalability)
構造特性
  • 構成容易性(Configurability)
  • 拡張性(Extensibility)
  • インストール容易性(Installability)
  • 活用性/再利用性(Leverageability/Reuse)
  • ローカライゼーション(Localization)
  • メンテナンス容易性(Maintainability)
  • 可搬性(Portability)
  • アップグレード容易性(Upgradeability)
横断的特性
  • アクセンシビリティ(Accessibility)
  • 長期保存性(Archivability)
  • 認証(Authentication)
  • 認可(Authorization)
  • 合法性(Legal)
  • プライバシー(Privacy)
  • セキュリティ(Security)
  • サポート容易性(Supportability)
  • ユーザビリティ/達成容易性(Usability/Achievalibity)

ISOでの定義

ISO / IEC 25010で定義
図と各項目の説明が記載されている(英語)
iso25000.com

パフォーマンス効率
  • 時間的挙動(応答、処理時間、スループット)
  • リソース利用率
  • 容量(設定された最大限度を超えるかなど)
互換性
  • 共存可能性
  • 相互運用性(複数のシステムとの連携)
ユーザビリティ
信頼性
  • 成熟度(通常の使用において信頼性要件を満たしているかどうか)
  • 可用性
  • 耐障害性
  • 回復性
セキュリティ
  • 機密性
  • 完全性
  • 責任追跡性
  • 立証性
  • 認証可能性
保守容易性
  • モジュール性
  • 再利用性
  • 分析容易性
  • 修正容易性
  • テスト容易性
可搬性
  • 適応可能性
  • インストール可能性
  • 置換可能性
機能適合性
  • 機能的完全性(機能が、特定のタスクとユーザーの目的をすべてカバーしている度合い)
  • 機能的正確性(製品やシステムが必要な精度正しい結果を提供する度合い)
  • 機能的妥当性(機能が指定されたタスクや目的の達成を容易にする度合い)

ISOでは定義されているが、本書ではアーキテクチャ特性としては扱わないと整理している。
(非機能ではなく、機能要件であるという考えという解説と理解)

トレードオフと少なくとも最悪でないアーキテクチャ

P66~P67 4.2 トレードオフと少なくとも最悪でないアーキテクチャより

アーキテクトがシステムを設計する上で、あらゆるアーキテクチャ特性を最大限に活かせることはほぼない。
ほとんどは、アーキテクチャ決定は競合する関心事間のトレードオフと帰着する。

決して最善のアーキテクチャを狙ってはいけない。
むしろ、少なくとも最悪でないアーキテクチャを狙おう。

 アーキテクチャ特性が多すぎると、あらゆるビジネス上の問題を解決しようとする汎用的なソリューションにつながる。
そうして作られたアーキテクチャは、扱いにくい設計となり、うまく機能することはほとんどできない。
 このことが示唆しているのは、アーキテクトはアーキテクチャをできるだけイテレーティブに設計するように尽力すべきということだ。

雑記

4章自体はとても短い章(P57~P66)であり、書いている内容も指針としての内容である。
とはいえ、ITアーキテクトに持つべき考え方などをとても分かりやすい言葉で纏めてくれている。
また、列挙した項目については、本書内では解説文を記載してくれている。