何を考えればアーキテクチャを扱っていることになるのか

　世はクリスマス一色になってきましたね。日頃、スロー・ライフをスローガンにしている私は、先日東京ディズニーランドにて実践に励んでまいりました（しかも、平日に）。この時期の見所は、ぷーさんでもバズライトイヤーでもなく、ホーンテッドマンションでしょ、やっぱり（期間限定だし）。＠ITの難しい記事に頭を悩ますのもよし、でも本記事（クリスマス前のNightmare）でリフレッシュするのもいいんではないでしょうかね？

ソフトウェア開発者ギルドへ

　我が愛する映画「Nightmare before Chiristmas（邦題：ナイトメアー・ビフォア・クリスマス）」では、主人公のJackがクリスマスにあこがれて、サンタクロースの真似事をします。でもJackはクリスマスではなく、ハロウィーンの主役……彼は「クリスマス」というコンテキストを理解することなく、形だけをまねることによって、恐ろしい結果を引き起こしてしまうのです。これまで個々のシステム開発現場でコードを書いてきたエンジニアが、キャリアアップの過程でアーキテクチャに責任を持たされるということがあります。この場合、（彼は）何を考えるとアーキテクチャを扱っているということになるのでしょうか？

RUPにおけるアーキテクチャの記述

　アーキテクチャは、システムの静的・動的両面の情報を持つ。アーキテクチャをモデル化するためには、何らかの整理された視点が必要になる。一例として、Rational Unified Process（RUP）におけるアーキテクチャ表現「4＋1ビュー」を紹介する。

　RUPでは、開発プロセスに関与する特定の利害関係者（例えば、ユーザー、設計者、管理者、開発者、運用管理者など）がシステムに対して持っている各自の関心事項を扱うために「ビュー」を定義し、それらを総称して、「アーキテクチャー・ビュー」と呼んでいる。以下の5つのビューで構成される（視点の違いを加味して「4＋1ビュー」と呼ばれる。

4＋1ビューとレイヤーパターン

　以下、イタリック部分は「Rational Unified Process 2003」からの引用である。

ユース・ケース・ビュー
アーキテクチャー上、重要な振る舞いやクラス、技術面でのリスクを含むユース・ケースとシナリオが含まれます。これはユース・ケース・モデルのサブセットです。

　アーキテクチャというと、システムの内部構造だけに気をとられがちだが、外部からみたシステムの振る舞いも重要な要素である。RUPでのアーキテクチャには、システムの振る舞いも含む。このビューでは、内部構造を決定する振る舞いやリスクを含むユースケースを中心にリストアップする。

論理ビュー
最も重要な設計クラスとそのクラスからパッケージとサブシステムへの編成、これらのパッケージとサブシステムからレイヤーへの編成が含まれます。いくつかのユース・ケース実現も含まれます。これは設計モデルのサブセットです。

　通常我々がモデリングと称する作業を行うのは、この論理ビューで行われる。中心となるクラスからそのグループ（＝パッケージ）、さらにグループ間の関係（ここでは1つの例として、レイヤー構造を挙げている）をモデリングする。実際にはクラス図だけではなく、動的側面を表すシーケンス図、ステートチャートも含まれる。

実装ビュー
実装モデルと、モジュールの観点からのパッケージとレイヤーへの編成の概要が含まれます。実装ビューのパッケージとモジュールへの（論理ビューの）パッケージとクラスの割り当ても記述されます。実装モデルのサブセットです。

　論理ビューは文字通り、論理的側面をあらわしており、実装面（例えばjarの編成）には踏み込まない。これを扱うのが実装ビューである。コンポーネント間の依存関係や、実利的コンポーネントと論理ビュー上の要素との関係付けを行っている。

プロセス・ビュー
関与するタスク（プロセスとスレッド）、そのタスクの相互作用と構成、タスクへの設計オブジェクトとクラスの割り当ての記述が含まれます。このビューは、システムにかなりの程度の並行性がある場合にのみ使用する必要があります。RUP では、設計モデルのサブセットです。

　同時並行アクセスに注意を払わねばならぬシステムの場合に、使われるビュー。筆者は業務系アプリケーションを主に手がけているが、プロセスビューを作ることはほとんどない。

配置ビュー
ほとんどの典型的なプラットフォーム構成のさまざまな物理ノード、物理ノードへの（プロセス・ビューの）タスクの割り当ての記述が含まれます。このビューは、システムが分散される場合にのみ使用する必要があります。配置モデルのサブセットです。

　物理的なコンピュータ資源を取り扱うビューである。お絵かきツールでコンピュータのアイコンを使って描いていたようなネットワーク構成図などが相当する。

　これらの情報は「アーキテクチャ設計書」というドキュメントにまとめられる。注意してほしいのは、どのビューにおいても、「サブセットである」という但し書きがあることだ。つまり、アーキテクチャビューというのは、次の特性を持つ。

1. 網羅性は問題にしていない。従来のプログラム説明書のような、すべてを記述することは意図しておらず、絞り込んでいる
   
   
2. 絞込みの対象となるのは、アーキテクチャを決定する上で影響を及ぼす要因と、その結果であるアーキテクチャである
   
   
3. ビュー間の関連性に注目している。それによって、思考の流れを整理している。どんなユースケースか？ （ユースケースビュー）
   

→これを実現するための、論理的な情報は？ （論理ビュー）
→論理的存在は物理的なモジュールとしてどう実現されるか？ （実装ビュー）
→活動状態にあるクラスはなにか？ （プロセスビュー）
→どの計算機資源で活動しているか？ （配置ビュー）

4＋1ビューとアーキテクチャパターンの関係

　一言でアーキテクチャとは言っても、どの範囲を考慮するかによって考慮すべきことは異なる。最近のはやり言葉「EA」（Enterprise Architecture）では、企業あるいは関連する企業グループ全体の基盤となるシステムの構造を、マクロ的視点から見て決定する。しかし、これは（私ごときが扱うには）荷が重過ぎる。本稿では、個別システムでのアーキテクチャ設計を対象に考えてみよう。

　GangOfFour（GoF）の「デザインパターン」の成功以来、設計に限らず、ビジネスモデルや分析といった抽象度の異なるレイヤーでも、パターン化するというのが、業界の流れである。アーキテクチャについても、パターン化が提案されている（*）。

*参考文献： 「Pattern-Oriented Software Architecture-A System of Patterns」（Frank Buschmann、Regine Meunier、Hans Rohnert、Peter Sommerlad、Michael Stahl著、John Wiley and Sons, Inc.1996.）

　アーキテクチャパターンは、システムの内部構造をどう分割するかのパターン集であり、その意味では、デザインパターンよりも大きな粒度のパターンである。業務系でのよく利用される代表的なものに、レイヤーパターンがある。レイヤーパターンは、システムの論理構造にフォーカスしているので、先ほどの4＋1ビューでの論理ビューで扱うことが対象となる。

　前回（「第3回 アーキテクチャ基礎講義」）の議論からおわかりいただけるように、アーキテクチャを考えるということは「システムの構造を抽象化する」ということにほかならない。データ項目の詳細やアルゴリズムの詳細を網羅的に考えるのではなく、そのシステムを特徴付けるモノに焦点をあてて考える。

○ 構造的側面

　コンポーネントステレオの例では、CDやDVDなど具体的なものを取り上げて構造を考えるという視点と、それらを音源という抽象的なものとして（構造を）考える視点があった。オブジェクト指向言語を使ったプログラミングでは、抽象的な概念もクラスとして扱う（世にいう抽象化）プログラミングが可能である。これを積極的に利用することで、再利用可能な基盤を作ることができる。

構造を考える視点

　利用する側の視点で抽象を考えると、「普遍的すなわち、業務のあちらこちらで共通して扱われる概念である。あるいは共通項の多い、処理プロセス」とみなすことができる。構造的側面では、抽象的な概念を扱うサブ構造と、そのシステムに依存した機能を実現するサブ構造とを区別し、それらの相関関係を定義する必要がある。

○ 個別システムに不可欠な要素

　個別システムでは、前述の構造的側面でのサブ構造が、どう相互作用することで所定の機能を実現するかを考えなければならない。この相互作用をモデル化するためには、

• 重要なユースケース（「ビジネス上、重要である」「ほかのシステムと連携する」）、主要なクラス
  
  
• 応答性能や信頼性要求、スケーラビリティ等の非機能的要求を解決するデザインパターン

などが必要になる。構造的側面では「どんな概念を扱うか？ その概念がどう分類できるか？」という視点から、主として抽象化の階層を考える。しかし、システムを稼動させるためには、それに加えて、システムでの実現手段を加味しなければならない。例えば、商取引のシステム化のコンテキストでは、次のように関心を捉えることができる。

1. ビジネスの視点では、顧客情報が取り扱うことが必須。顧客情報として何を扱うかが重要
   
   
2. システム視点では所与の性能要求の範囲内で操作する手順を考慮する必要がある。例を示そう。データベースへのアクセス手順は、それを利用するアプリケーションとは別個に定義されている（それをSQLという言語や専用のAPIで利用する）。つまりここではビジネス的な観点とシステム的な観点で内部構造を分割することができる

　これまでのところをまとめると、アーキテクチャを考慮するときの基本方針は、以下のようになる。

（A） ビジネス上の概念を、普遍的、一般的な概念と、個別システムに閉じた概念とに分離し、関係を整理する

（B） ビジネス上の概念とシステム化するために必要な仕組みとを分離する

クラス構造の分割

　通常、分析や設計の初期では、クラスの数がさほど多くない。しかしパフォーマンスや性能などを考慮すると、クラス構造を分割せざるを得なくなる。したがって、前期の方針に従って見出されたクラスは、設計の初期モデルでパッケージにマッピングされることが多い。これにより、分割されたクラス群（パッケージで代表）と分析レベルでのクラスとの対応付けがやりやすくなる。

Jackはクリスマスを理解したか？

　J2EEや.NETというプラットフォーム毎にあるべきアーキテクチャ論が語られており、＠ITのサイトでもそれに関する記事が出ている（例えば「建築家の視点、アーキテクトとしての共通認識」）。プラットフォームを意識する中でのアーキテクチャ論の詳細はそちらをご参照いただきたい（「IT アーキテクト フォーラム」）。だが、アーキテクチャを導き出す思考の方針はいずれも共通している。結果としてのアーキテクチャよりも、その思考法のほうが重要であるのはいうまでもない。まとめとしてその手順を簡単に示そう。

1. 細かいシナリオを網羅するのではなく、重要なユースケースに注目し、それを実現するために必要な、情報を整理する。例えば……、
   
   ・外部システムとの連携
   ・性能や信頼性といった、機能以外の要求事項
   ・ドメインを構成する主要な概念
   
   
2. 一般性の度合いによって、1の概念を分離する
   
   
3. コンピュータでの実現手法と、概念を分離する
   
   
4. 各々をパッケージとして、依存関係を整理する

　プラットフォームの勉強に加えて、業務ドメインのアーキテクチャ化も重要な課題である。これを幹とできれば、システムはどんどん発展し、やがて雲を突き抜けて、Jackはいつしか大空へ（……って、それは「Jackと豆の木でしょ」）。

ソフトウェア開発者ギルドに戻る