【プリンシプルオブプログラミング】アーキテクチャ非機能要件

目次

はじめに

この記事は「プリンシプルオブプログラミング」を読んで自分なりにまとめた学習メモです。 

プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則

思想　〜プログラミングのイデオロギー〜

非機能要件

非機能要件とは、機能面以外の全般についての要件のこと。

６つの観点

• 変更容易性
• 相互運用性
• 効率性
• 信頼性
• テスト容易性
• 再利用性

変更容易性

変更容易性とは、どれだけ容易に改善できるか、という能力のこと。

【具体的に】

• 簡単に修正できるか
• 簡単に拡張できるか
• 簡単に再組織できるか
• 簡単に別のプラットフォームに移行できるか

【意識すべきこと】

• 保守性
• 拡張性
• 再構築
• 移植性

相互運用性

相互運用性とは、ソフトウェアが、ほかのソフトウェアとやりとりできる能力のこと。

【意識すべきこと】

標準規格を選択する。外部の機能やデータ構造へ、アクセスが明確に定義されたアーキテクチャを設計する。

効率性

効率性とは、ソフトウェアが、実行に伴うリソース使用において、適切な性能を引き出す能力のこと。

【２つの観点】

• 時間効率性：スループット、レスポンスタイム、ターンアラウンドタイムなどで計測する
• 資源効率性：CPUの使用時間、メモリ使用量、ストレージ消費量、ネットワーク転送量などで計測する

【意識すべきこと】

コンピュータのリソースを、適切に利用する。

あるものは有効活用して、ソフトウェア性能を最大限引き出すということ。節約することも必要だが、活用するという観点でもアーキテクチャを設計する。

信頼性

信頼性とは、ソフトウェアが、例外的な場面、予期しない方法や不正な方法で使用された場面においても、機能を維持する能力のこと。

【２つの側面】

• フォールトトレランス：ソフトウェアに障害が発生した時に、正常な動作を保ち続ける能力。
• ロバストネス：不正な使用方法や入力ミスから、ソフトウェアを保護する能力。

【フォールトトレランス観点の対策】

アーキテクチャに内部的な冗長性（二重化など）を持たせるようにする。

また、障害時に、提供する機能を絞り込み、大事な機能のみを提供して処理継続を優先する設計（フェールソフト）も考慮する。

【ロバストネス観点の対策】

障害時に、その部分を切り離す設計（フェールセーフ）を検討する。

また、そもそも障害が発生しないように、あらかじめユーザが誤った操作を行っても安全に稼働させる設計（フェールプルーフ）も考慮する。

テスト容易性

テスト容易性とは、ソフトウェアに対して、「効果的」かつ「効率的」にテストを行う能力のこと。

• 効果的：テストが深く、質が高いこと。
• 効率的：テストのコストや労力が少ないこと。

【意識すべきこと】

アーキテクチャの策定の時点から、検証方法の観点も含めて設計する。

テストコードは、本番コードに従属するイメージだが、テストのためのコードが本番にあっても構わない。テストしやすくするための構造が、本番コードにあっていい、というくらい価値観の転換が必要。それぐらい、テストは重要。

テスト容易性のための設計では、モジュール間の依存関係の排除がポイントになる。依存関係があると、テストがしにくい部分に、全体が足を引っ張られる可能性が高くなる。極力、依存関係を排除し、小さい単位でテストが可能となるように設計する。

再利用性

再利用性とは、ソフトウェアを、全体でも一部でも、別のソフトウェアの開発に再利用する能力のこと。

【２つの側面】

• 再利用するソフトウェア開発：ソフトウェア内の既存モジュール、以前のプロジェクトのモジュール、各種ライブラリなどを利用することを意味する。再利用可能な成果物を、開発中のソフトウェアに、そのまま、あるいは変形して統合する。

• 再利用のためのソフトウェア開発：将来のプロジェクトで再利用できるようなモジュールを、現在のソフトウェアに再利用されるためのソフトウェア開発で創出することを意味する。他のソフトウェアに再利用されるためのソフトウェアを開発する。

【意識すべきこと】

再利用するソフトウェア開発の場合、アーキテクチャの構成を、既存の構造やモジュールに「プラグイン」できるようにする。独立してビルドできるようなモジュールにしパッケージにしておく。