ソフトウェアアーキテクチャ その4 - アーキテクチャ決定要因と品質特性 [arch]
今回は，最も重要なアーキテクチャ決定要因である品質特性について.
優れた設計とは要件が忠実に反映されたものであり，その為にはそもそも要件が正しく分析されていなければならない．ステークホルダーから言い渡される非常に抽象的かつ曖昧な要件を体系的に構造化するのは，アーキテクトの責務の1つだ．
Reference:
Software Architecture in Practice, Second Edition,
by Len Bass, Paul Clements, and Rick Kazman, Addison-Wesley 2003
--> Chapter 4
|
タイトルの "in Practice" (実践における) が示す通り，様々なケーススタディを交えつつ，非常に具体性のある内容になっている．
こちらがその和訳本．
一般的に，要件は
- 技術制約 (Technical Constraint)
- ビジネス制約 (Business Constraint)
- 機能要件 (Functional Requirement)
- 品質特性 (Quality Attribute)
の4つに分類され，これらはアーキテクチャ決定要因 (Architectural Drivers) と称される．
制約とは，アーキテクトが自由度を持たない，既に決定された設計方針を指す．例えば，採用が決まっている OS やライブラリ，ROM/RAM サイズなどは技術制約にあたり，決められた納期や与えられたヒューマンリソースなどはビジネス制約にあたる．技術制約を「直接的制約 (Direct Constraint)」ビジネス制約を「間接的制約 (Indirect Constraint)」と呼ぶこともある．
機能要件はシステムが実現するべきことを指す．特に設計時には，実装時に考慮するような粒度の細かい機能と区別する為に "High Level Functional Requirements" と呼ぶこともある．
品質特性とは機能の他にシステムが保有するべき性質のことで，「システムが実現するべきこと」に対して「それをどう実現するか」について言及する．
ちなみに，機能要件の "functional requirements" に対して "non-functional requirements" というものを定義し，この中に品質特性を含めている解説を見かけることがあるが，これは間違いなので注意したい．機能要件と品質特性は密接に絡む場合が多く，"non-functional" という言葉は要件のパーティショニングに完全に失敗している．呼び方や言葉選びに固執することは極力避けたいが，ここだけは明確にしておきたい．
さて，一番分析が難しく，かつ一番見落とされがちなのが品質特性である．一般的に「要求仕様」と言うと機能要件だけが語られる場合が多く，それだけを念頭に設計しがちだが，機能要件はシステムの構造に依存しない．アーキテクチャを大きく決定付けるのは品質特性であり，設計の初期段階から検討に組み込まれている必要がある (システムが完成してから「これでは遅すぎる」と言われた経験はないだろうか?)．極論を言えば，単一モジュールのコードの塊だって，機能要件を実現することはできる．
以下，この品質特性について詳細に解説したい．
ソフトウェアが実現するべき品質の特性は
- Availability (可用性)
- Modifiability (変更容易性)
- Performance (性能・速度)
- Security (堅牢性)
- Testability (テスト容易性)
- Usability (使いやすさ)
の6つに大きく分けられる．
そして品質特性の分析に非常に有効なツールが，「品質特性シナリオ (Quality Attribute Scenario)」である．機能要件の分析にはユースケースを，品質特性の分析には品質特性シナリオを用いる場合が多い．
品質特性シナリオは，文字通りシステムが備えるべき品質特性のシナリオを記述するというもので，以下の6つの要素から成る．
1. Stimulus (刺激)
システムに影響を与えるコンディション
2. Source (発生源)
Stimulus を生み出した要素
3. Environment (環境)
Stimulus が発生した状況・環境
4. Artifact (成果物)
Stimulus によって刺激を受けた成果物
5. Response (応答)
Stimulus によって持たらされるべき動作
6. Response measure (応答測定)
評価可能なシステムの応答単位
本書ではシステム非依存の "general scenarios" という形で解説されているが，実際に分析する際にはシステムに特化した "concrete scenarios" を検討したい．
例えば，とあるポータブルオーディオプレイヤーの，performance 品質特性シナリオの1つは，
通常使用時に，ユーザーがコンテンツリストから任意の曲を選択した場合，100ms 以内に画面をコンテンツリストから曲の詳細情報画面に切り換え，1秒以内にその曲を再生し，3秒以内にその曲のタイトルとアーティスト情報を画面に提示すること．
みたいなものかもしれない (刺激: コンテンツリストからの選曲 / 発生源: ユーザー / 成果物: システム / 環境: 通常使用時 / 応答: 画面を詳細情報画面に切り換える・曲を再生する・曲のタイトルとアーティスト情報を画面に提示する / 応答測定: それぞれ100ms以内・1秒以内・3秒以内)．
ただ現実的に受け取る要求は最初からここまで情報が揃っておらず，
システムの全てのイベントにおける応答速度はできるだけ早いことが好ましい
とか
サーバーが故障した場合の被害が最小限になるようにバックアップ装置を設置すること
ぐらいのレベルではないだろうか．両者とも，品質特性シナリオを書こうとすると6つの要素全てが欠落している，あるいは不十分なことが分かる．
このように，品質特性シナリオ (シナリオ文章を書くことに個人的にはこだわらないが，6つの要素にブレイクダウンすること) は，設計に落とし込めるような形で記述されていない要求を具体的に分析すること，足りない情報が何かを把握すること，要求の中に複数の品質特性が重複していたり異なる要素が混ざっていないかを認識することなどを可能とする．
各品質特性の General Scenario については，本書の4.4章 "Quality Attribute Scenarios in Practice" か，同じ内容が解説されている
http://softarchpract.atw.hu/ch04lev1sec4.html
を参照頂くとして，ここでは各品質特性について，ポイントとなるところに触れておきたいと思う．
Availability (可用性)
→ Table 4.1: Availability General Scenario Generation
システムの障害とそれが発生した場合の反応について扱い，本書では "failure" と "fault" という言葉を明確に分けて使用している．
Availability の要件には，機能要件や他の品質特性を伴うことが多い．
まずそもそも「障害を発見すること」という機能要件があるだろうし，その場合に「何秒以内に復旧すること」といった performance が求められることもあるだろう．
Modifiability (変更容易性)
→ Table 4.2: Modifiability General Scenario Generation
変更のコストについて言及する．特に注目するのは，「何を変えるのか (成果物)」と「誰がいつ変えるのか (環境)」だ．
良く犯す間違いは，「システムをアップグレードする際に影響を受けるモジュールは3つ以内とする」といった応答測定を定めてしまうことだ．モジュール分割を行う前の要件分析の段階で，システムにいくつモジュールがあるかは分からない．
つまり「モジュール3つ以内」という応答測定は，設計を先走ってしまったか，後から要件のつじつま合わせをしているか，まったくデタラメかのいずれかである．Modifiability は，コストの概念 (時間や金額) で測定されるべきだ．
また，Modifiability はアーキテクチャ設計だけではなく，実装時のコーディングテクニックによっても多分に持たらされる (Modifiability が促進された美しい設計を実装で台無しにすることも可能だ)．
Performance (性能・速度)
→ Table 4.3: Performance General Scenario Generation
タイミングやデッドラインの概念である．様々なイベント (割り込み，メッセージ，ユーザーアクション，時間経過など) に対して，システムがどれぐらいの速度で応答するかを言及する．
Performance もまた，コーディングテクニックや採用するアルゴリズムによって持たらされることもあるだろう．
また，Performance 以外のほとんどの品質特性は，Performance にマイナスの影響を与えるのも重要なポイントだ．
Security (堅牢性)
→ Table 4.4: Security General Scenario Generation
システムの，侵入や不当な使用方法に抵抗する能力であり，具体的には non-repudiation (トランザクションが拒絶されないこと)，confidentiality (データやサービスが許可を持たないユーザから守られること)，integrity (データやサービスが改ざんされることなく意図通りに届けられること)，assurance (取引相手が意図通りの人間であること)，availability (システムが正規に使用可能であること)，auditing (再現可能なレベルまでユーザーアクティビティが記録されていること) などに特徴付けられる．
Testability (テスト容易性)
→ Table 4.5: Testability General Scenario Generation
ソフトウェア開発コストの40%がテストに費やされているとも言われており，testability を上げるというのは実はコスト削減に大きく影響する．
Usability (使いやすさ)
→ Table 4.6: Usability General Scenario Generation
ユーザーがいかに容易にやりたいことを満たせるか，あるいはシステムがどのようなユーザーサポートを供給するか，といった概念である．
要求の中に「GUI」とか「ボタン」などというキーワードがあるだけで，すぐに usability に結びつけて考えるのは危険だ．例えば「画面が安定して動作していること」や「フォーカス動作がキビキビしていること」などにユーザーは便利さを感じるだろうが，前者は availability，後者は performance である．
また，前回の番外編 でも少し触れたが，usability には non-architectural な要素も多い．「ラジオボタンかチェックボックスか」「直感的なスクリーンのレイアウトは?」などといった方針決定はアーキテクチャ設計にはあまり関係がないはずだ．一方で「ユーザーがオペレーションをキャンセルしたりアンドゥーできること」や「入力済みのデータを再利用できること」などはアーキテクチャ設計に影響を与えそうだ．
ところで上に示した6つ以外にもシステムの特性を示す言葉はいくつもあり，例えば「スケーラビリティ」「ポータビリティ」「インターオペラビリティ」などは実際の現場でも良く聞かれるだろうし，他にもざっと挙げるだけでこれぐらいあるだろう．
Ilities - Wikipedia, the free encyclopedia
結論から言えば，これらの言葉にたいした意味は無い．例えば「システムが modifiable である」という言葉は何も語っていない．とある品質特性が，どの "Ilities" なのかよりも，品質特性シナリオにおいて6つの要素に分解すること，特に応答測定を明確に定めることが極めて重要である．測定方法が分からないのに，設計を行うことはできない．某アーキテクトの言葉を借りれば，"Know the answer to the test, before you take the test" ということだ．
また要件分析において注意したいこととして，「ソリューションにすり変わってしまっている要求」がある．特に技術者やその出身者からの要求に多いが，この類はまるごと疑ってかかった方が良い．例えば「…の時には関連するプロセスを再起動すること」とか「ハートビートを監視して…」などと言う要求．なぜ設計する前からプロセスがあることが分かる? なぜ停止ではなく再起動することが安全だと言える? なぜハートビートという実装方法にまで言及している? これらが「本当に満たしたいこと」を疎かにして要件を履き違えた結果なのか，明確な理由を持つ技術制約なのかは真っ先に確認するべきだ．
上流設計においてシステムをモジュール分割する過程で，機能要件はあるモジュール1つ1つにアサインされる (特定のモジュールが特定の機能を実現する責務を持つ) のに対し，品質特性は「システムの分割の仕方そのもの」によって持たらされる場合が多い．これが品質特性がアーキテクチャを決める最大の理由なのである．
以上で品質特性を中心としたアーキテクチャ決定要因の大枠については説明できたと思う．本書の4.6章には "Business Qualities" という特性も説明されているが，これはあまり現実的な概念ではないので，読み飛ばしてしまって良いだろう．
最後に重要なことを1つ．
品質特性はタダで手に入るものではない．採用する architectural pattern や次回述べる tactics など，アーキテクチャの方針決定には全てトレードオフが伴う．1つ1つの決定が，特定の品質特性を促進し，同時に特定の品質特性を抑制する．このトレードオフのバランスを取ることこそ設計の本質であり，それを確実に見極める為には要求を詳細に分析するだけではなく，その優先順位を正しくつけ，さらにその内容についてステークホルダーから合意を得ておくことが不可欠だ．優先順位設定まで含めた要件分析なしに，システムのバランスを取ることは不可能である．
以前書いた，今回の内容に良く似た記事もご参考に．
Peace Pipe: ソフトウェアアーキテクチャを決定するのは品質特性 [memo]
0 コメント:
コメントを投稿