アーキテクチャ戦術の適用

この記事は、Peter Cripps氏による、「Applying Architectural Tactics」を、ご本人の許可を得て翻訳したものです。*1


Software Engineering Instituteによって提案されたアーキテクチャ戦術の使用は、システムの非機能要件(システムの品質、または単に品質とも呼ばれる)を扱うための体系的な手法を提供する。これらは、パフォーマンスや可用性、セキュリティなどの実行時の品質と、保守性や移植性などの非実行時の品質の両者からなりうる。私の経験では、機能要件と非機能要件の両者を扱うことは、それらを適切なモデリングツールで把握することと同じく、いつも体系立って扱うことができるとは限らないものである。以下は、Unified Modeling Language(UML)とUML準拠ツールを使用して、いくらかのアーキテクチャ的な厳密さを実現しようとするためのアプローチである。

図1を時計周りに見ていくように、アーキテクチャ的にはシステムは、エンタープライズ/またはシステム全体のビュー(つまり、人々やプロセス、データやITシステム)から、ITシステム・ビュー、コンポーネント・ビュー、そして最終的にはサブコンポーネント・ビューへと分解することができる。これらの図はホテル管理システムの例(以前アーキテクチャ原則を説明する際にも使用したもの)がどのようにして最終的にはコンポーネント、そしてサブコンポーネントに分解されるかを表している。

f:id:GOLEM-XIV:20110506003259j:image

図1: システムの分解

典型的にはこの分解は、異なる分解のレベルにおいて、どの機能が各システム要素に関連付けられる必要があるかを考えることによって行われる。よって、図1に示したように、初めは”大きな粒度”の機能(例えば、我々はホテルシステムが必要)をシステム・レベルにおいて関連付け、そしてすべての機能をすべてのコンポーネントに関連付けるまで(例えば、我々はシステムの顧客管理を扱うユーザー・インターフェース・コンポーネントが必要)、徐々により細かい粒度のレベルに、ブレークダウンしていく。

コンポーネント配置の観点からは、個々のコンポーネントのタイプ(つまり、それらはユーザーの入力を扱うのか、それともデータを管理するのか、など)について明確な考えを持てるように、そしてそれらがユースケースを満たすためにどのように協調するかを知るために、少なくとも図1のサブコンポーネントのレベルまで、システムを分解することが必要である。これを行うために使用できるパターンは数多く存在する。例えば、図2のModel-View-Controllerパターンは、コンポーネントがどのように協調するかというルールを使用して、機能をコンポーネントに帰するための一般的な方法である。このパターンは図1のサブコンポーネント・ビューで使用されている。

f:id:GOLEM-XIV:20110506003258j:image

図2: Model-View-Controller パターン

ここまでは、システムを機能要件をベースにして分割する方法と、どのコンポーネントがそれらの要件を実現するかについての考え方を示した。それでは、非機能要件はどうなるのだろうか?表1は非機能要件が分解され、そして特定されたアーキテクチャ要素に割り当てることができることを表している。はじめに、非機能要件はシステム全体のレベルで述べられるが、徐々により細かい粒度のアーキテクチャ要素(コンポーネント)に分解されていくに従い、それらの要素がどのように特定の非機能要件をサポートするかも考え始めることができる。この方法によって、非機能要件は分解され、各レベルのシステム機能に関連付けられる。非機能要件は理想的には個々の適切なコンポーネントへ、属性として割り当てられるため(我々が選択したUMLモデリングツールの内部でそのようなことを行えることが望ましい)、それらは失われたり、忘れられたりすることはない。

Table 1 システム要素と非機能要件

システム要素 非機能要件
ホテルシステム (すべてのアクターとITシステムを含む) ホテルシステムは、顧客に対し、365日24時間のチェックインを可能としなければならない。これは初期の段階で述べられる非機能要件の、典型的な精度であることに注意。通常、測定可能な値とするためには更なる分析が必要。
ホテル管理システム(ホテルのITシステム) ホテル管理システムは、フロントデスクの事務員に、365日24時間、99.99%の可用性で、顧客のチェックインを行わせることができなければならない。
顧客管理(ホテルITシステム内のシステム要素) 顧客管理のシステム要素(コンポーネント)は、顧客詳細の作成、読み取り、または更新(削除は無し)を、365日24時間、99.99%の可用性で行うことができなければならない。
顧客管理インターフェース(顧客管理のシステム要素に属するユーザー・インターフェース) 顧客管理インターフェースは、顧客詳細の作成、読み取り、または更新(削除は無し)を、365日24時間、99.99%の可用性で行うことができなければならない。

一度各コンポーネントがどの非機能要件をサポートする必要があるかが理解されれば、それらの非機能要件をどのように扱うかを決定するために、Software Engineering Institute (SEI)によって提案されている、アーキテクチャ戦術のアプローチを適用することができる。

アーキテクチャ戦術は、1つ以上のパターン、または理論的なフレームワーク(例えば待ち行列やスケジューリング理論)をアーキテクチャに適用することで、非機能要件をどのように満たすかについての、”成文化された知識”である。戦略は、望ましい能力を達成するために、アーキテクチャ上の決定を通じて、非機能要件(のパラメータ)をどのように扱うことができるかを表す。

表1の例では、顧客管理インターフェースによって達成されるべき、99.99%の可用性(一年あたり、52分34秒のダウンタイムに相当)という、望ましい品質属性を達成する戦術が必要である。可用性に関する戦術の詳細なセットはここで見つけることができるが、この例の目的のためには、可用性に関する戦術を、欠陥検出、リカバリ、そして防止のいずれを扱うのかによって、カテゴライズすることができる。以下は、戦術として考えられるいくつかの例である。

  • インターフェースの設計、実装に対し、コードインスペクション、ユーザビリティテストなどの、欠陥検出のための良いソフトウェア・エンジニアリングのプラクティスを採用する。
  • システムのモニタリング、アクティブ・フェイルオーバーなど、欠陥検出やリカバリのアプローチを持つ高可用性プラットフォームへ、コンポーネントを配置する。
  • 目標可用時間内に、実行中のユーザーインターフェースを置き換えることができるような、バックアップやリカバリのアプローチを開発する。

この例が示すように、すべての非機能要件が、コンポーネント単体で適切に実現できるわけではない。完全な実現は、適切なコンピュータ・プラットフォームの上に配置されることによってのみ、達成されるかもしれない。一度どの非機能要件が、どのコンポーネントによって実現される必要があるかを知ってしまえば、その非機能要件をサポートする、適切なコンピュータ・プラットフォームに配置するために、それらのコンポーネントを一緒にパッケージングする方法を考えることができる(例えば、99.99%の可用性をサポートするプラットフォーム上、など)。図3はこの配置が、「ホット・スタンバイ・ロード・バランサー」パターンを採用することで、UML中でどのようにモデリングできるかを表している。

f:id:GOLEM-XIV:20110506003257j:image

図3: 配置ビュー

ここでは、”顧客管理”という一つのコンポーネントを取り上げ、そしてそれがどのようにして、同じ非機能要件をサポートする他のコンポーネント(”客室管理”と”予約管理”)と一緒に、2つのアプリケーション・サーバーのノードに配置されるかを示した。3つめのUML要素である”アーティファクト(artefact)”(訳注:図中のServer Components)は、 UMLの«manifest» で関連付けられるようなコンポーネントを一緒にパッケージングする。実際にノードに配置されるのは、アーティファクトである。アーティファクトは、”モデル要素を具体化、または明確化し、パッケージ可能な要素の使用方法を表す表明を持つ”ことを表す、標準的なUML要素である。

ここまではすべて論理的なレベルである。つまり、テクノロジーに関する言及はなかった。しかしながら、論理的なレベルから物理的(テクノロジー依存レベル)なレベルへの移行は比較的単純なステップである。アーティファクトのパッケージング記法は物理コンポーネントのパッケージでも、同じように使用することができる。例えば、図3における3つのコンポーネントは、Enterprise Javaや.NETのコンポーネントかもしれない。

以上は、次の3つの重要な点を説明するための簡潔な例であった。

  • 機能・非機能要件に基づく、システムのアーキテクチャ作成。
  • 標準的な記法(UMLなど)とモデリング・ツールの使用。
  • どのようにしてシステム品質を達成できるかを表すための戦略とパターンの適用。

以上のアプローチは、ロケット工学(訳注:複雑で難しいもののこと)ではないが、実際に行われるのをあまり見ることが無いものだろう。


(翻訳者のコメント)

本entryやSEIなどのドキュメントを読むと、欧米の人々の「物事をパターン化する」ことに対する、強い情熱を感じます。デザイン・パターンやアナリシス・パターンなんてのは有名ですし、最近ではDomain-Driven Designもパターンの形式で書かれています。アリストテレス以来の流れでしょうか。

最近はだいぶ変化しましたが、このあたりは、職人芸(暗黙知)というものに重きを置いてきた日本との違いを感じます。どちらがいいかというのは一概に言えませんが、このようなカタログがあるということを知っておくことは非常に有用だと思います。

*1:原文公開日:2011年4月15日。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です