ラショナル統一プロセス(Rational Unified Process: RUP)のアーキテクチャ設計(Architectural Design)は、RUPの「推敲フェーズ」の営みを前提とした上で、テンプレート化とフレームワーク化が可能になる。「コンポーネントベースのアーキテクチャを利用せよ(Use Component-based Architectures)」というRUPのベストプラクティスを前提とすれば、アーキテクチャ設計として網羅すべきなのは自ずと限定されてくる。以下では、アーキテクチャ設計の各項目の背景知識をまとめて、その上でアーキテクチャ設計のサンプルを提示したい。
概要
- 1 RUPのアーキテクチャ設計で言及すべき項目
- 2 「問題設定」で言及すべきこと
- 3 まとめ
- 4 （サンプル）既存トラッキングシステムのファーストパーティクッキー対応に関するアーキテクチャ設計書
- 5 参考文献
RUPのアーキテクチャ設計で言及すべき項目
- 問題設定
- アーキテクチャの決定
- システムの構成
- 設計の観点
- 4+1ビューに関する注意点
- ユースケース・ビュー
- 論理ビュー
- 実装ビュー
- プロセス・ビュー
- 配置ビュー
- データモデル
- 非機能要求
- 開発の構成
以下では、これらの項目について、どのような論点や観点で何を記述すべきなのかについて、一つずつ補足しておく。しかしソフトウェア要求定義の場合に比べ、ここでは最初の「問題」についてかなり深く論究していかなければならない。と言うのも、「問題設定」が浅墓では、後の全てのアーキテクチャ設計が破綻するからだ。そのため以下の詳述では、「問題設定」にかなりの分量を割いている。反面、「データモデル」と「非機能要求」と「開発の構成」に関しては、アーキテクチャ設計に特有の項目ではないため、説明は最小限に抑える。
「問題設定」で言及すべきこと
ここでいう「問題設定」は、実際には問題の再設定である場合が多い。と言うのも、「問題」は既にソフトウェア要求定義の時点で設定されているからだ。アーキテクチャ設計では、既に設定済みである「問題」をアーキテクチャ・セントリック・デザインの観点から再設定することになる。
ソフトウェア要求定義におけるユースケース駆動型の漸進的な開発プロセス
ソフトウェア要求定義はユースケース駆動型として実践される。それは「顧客」や「エンドユーザ」が直面している個別具体的な「問題」に対する「問題解決策」を分析する営みだ。個別具体的であるのだから、そうした「問題」は、「顧客」や「エンドユーザ」が置かれる状況や状態において様々となる。故にユースケース駆動型の開発においては、各「問題」に対する「問題解決策」としての「システム」を積み上げていく漸進的(Incremental)な開発を繰り返すことになる。
しかしこの場合、個々の「問題解決策」としての「システム」の抽象化の余地が盲点になる。確かに現場を観察するなら、個々の「顧客」や「エンドユーザ」が直面している個別具体的な「問題」はそれぞれ異なっているだろう。しかしその中にも、「共通性」はあるはずだ。それを探索せずに、闇雲に個別具体的なユースケースに対応した「システム」を開発してばかりでいれば、リソースが間に合わなくなる。
アーキテクチャ設計におけるアーキテクチャ中心主義的な反復型の開発プロセス
そこでアーキテクチャ設計では、この「共通性」との関連からアーキテクチャ・セントリック・デザインを重視することになる。個別具体的な「問題」に対する「問題解決策」としての「システム」の「共通性」を前提に抽象化された「システム」をコアとなるアーキテクチャと見立てることで、そのアーキテクチャを実装すれば「共通性」を有した複数の「問題」に可能な限り一挙に対応し得る「問題解決策」を獲得できるようになる。
アーキテクチャ・セントリック・デザインを採用した場合、そのプロセスは反復型(Iterative)になる。反復型の開発では、ソフトウェアの全体や部分に関して、最初は最低限のコンポーネントとして開発し、その後徐々に肉付けしていく方法を採る。コアとなるアーキテクチャを始めに実装してしまえば、大方の「問題」には対応できるようになる。それだけで開発プロジェクトも大分進捗したことになるという訳だ。
アーキテクチャ設計における問題の（再）設定で実践すべきこと
ソフトウェア要求定義におけるユースケース駆動型の漸進的な開発プロセスと、アーキテクチャ設計におけるアーキテクチャ中心主義的な反復型の開発プロセスに関する以上のような差異を前提とするなら、アーキテクチャ設計における問題設定で実践すべきなのは、ソフトウェア要求定義の時点で設定していた「問題」と「問題解決策」の抽象化であるということになる。
オブジェクト指向設計思想を前提とすれば、この抽象化はクラス(Class)の抽出を意味する。ジム・コプリエンの「共通性／可変性分析(commonality / variability analysis)」を参考にするなら、このクラス抽出は、「共通性」と「可変性」の区別を導入することで可能になる。
オブジェクト指向の前提背景にある「概念水準」・「仕様水準」・「実装水準」の差異を前提とするなら、「共通性」の分析は、オブジェクト指向における「概念水準」と「仕様水準」を対象とする。一方「可変性」の分析は、オブジェクト指向における「仕様水準」と「実装水準」を対象とする。それぞれ確認しておこう。
「概念水準」と「仕様水準」を対象とした「共通性」の分析
「共通性」の分析では、まず「概念水準」として認識される諸概念の中から汎化や集合によって共通化できる対象を探索することになる。そのためには、ソフトウェア要求定義の時点で果敢にオブジェクト図や概念クラス図の作画を試みることが重要になるだろう。
更に「仕様水準」においても、「共通性」は見出せる場合が多い。「仕様水準」の観点によって、特定の概念との関連から記述できるユースケースの全てにおいて再利用可能なインターフェイスを洗い出すことができる。つまり「問題A」と「問題B」は共通してこの「インターフェイスX」を利用することになるという点で、「インターフェイスX」を「共通性」として抽出することができる訳だ。
「仕様水準」と「実装水準」を対象とした「可変性」の分析
「可変性」の分析では、「仕様水準」に対応する公開インターフェイスによって相対的に隠蔽されるべき「コードの差異」を「特殊なユースケース」として特定しておくことが求められる。全ての「問題」に対する「問題解決策」となり得る「銀の弾丸(Silver bullet)」などあり得ない。アーキテクチャ設計では、「共通性」の抽象化の対象外となる個別具体的な「問題」にも対応しなければならない。
抽象クラスと具象クラスの区別
共通性／可変性分析では、「共通性」の分析結果として発見された諸要素を相対的に抽象的なクラスとして記述する一方で、「可変性」の分析結果として発見された諸要素を相対的に具象的なクラスとして記述する。言い換えれば、「共通性」と「可変性」の関連は「クラス階層」に対応付けられる。こうして抽出された諸クラスの関連をUMLの「詳細クラス図」として視覚化していく。
こうして発見された比較的抽象的なクラスは、コアとなるアーキテクチャの候補となり得る。抽象クラスがコンポーネント・アーキテクチャとして機能し得るという発見を得ることが、共通性／可変性分析の醍醐味であるとも言える。
「問題設定」で言及すべきことのまとめ
以上の論点をまとめると、アーキテクチャ設計における「問題設定」で言及すべきなのは、共通性／可変性分析によって発見された抽象的なコンポーネント・アーキテクチャを前提とした上で、「問題解決策」として機能するコアとなるアーキテクチャから「問題」を「逆算」するかのように再設定することであると考えられる。
「問題設定」の一例
- ソフトウェア要求定義書（サンプル）によれば、次の機能が実装されなければならない。
- 計測タグ発行機能
- 計測タグのファーストパーティクッキー埋め込み機能
- 計測タグのファーストパーティクッキー参照機能
- 計測タグの成果発生可否判定機能
- トラッキングシステムの管理画面における計測機能
- しかし、既存のトラッキングシステムを視野に入れた共通性／可変性分析を実施するなら、「可変」となるのは、本来サードパーティークッキーを前提に処理していた部分に限定される。
- したがって、本開発プロジェクトで解決すべき問題となるのは、サードパーティークッキーを前提とした処理部分からファーストパーティクッキーを前提とした処理部分への切り替えが如何にして可能になるのかであるということになる。
「アーキテクチャの決定」で言及すべきこと
「問題設定」における分析が十分であれば、今や「アーキテクチャの決定」で言及すべき点も明快になっているはずだ。上述した「問題設定」それ自体が、「問題解決策」として機能するコアとなるアーキテクチャから「逆算」するかのように実践されている。ならば、そのコアとなるアーキテクチャを明示すれば良い。
「アーキテクチャの決定」の一例
- 本開発プロジェクトにおけるコアとなるアーキテクチャは、サードパーティークッキーとファーストパーティクッキーの切り替え処理を備えた計測タグ発行機能に他ならない。
「システムの構成」で言及すべきこと
この項目では、先述したコアとなるアーキテクチャとそうではないコンポーネント・アーキテクチャ同士の関連をコンポーネント図のアセンブリコネクタなどによって視覚化することが求められる。コンポーネントによって各サブシステムの「概念水準」的な位置付けを明確化すると共に、アセンブリコネクタによって各サブシステムの「仕様水準」における公開インターフェイスを明確化していくことが目指される。
「システムの構成」の一例
「設計の観点」で言及すべきこと
この項目からは「システムの構成」で視覚化されたシステムの全体像のうち、特に注意すべき観点となる部分を「サブセット」として取り上げる。RUPの「4+1ビュー」に倣い、クラス設計やシーケンス設計のもと、いわゆる「非機能要求」も考慮する。
「4+1ビューに関する注意点」で言及すべきこと
「4+1ビュー」という設計観点に対する誤認を防ぐために、以下の内容は、全てのアーキテクチャ設計書に記載しておくべきだろう。
- 設計担当者が必要と考えるビューのみに言及するため、製作すべきプログラムの全てを網羅することは最初から意図していない。
- このビューの絞り込みにおいて重要視しているのは、アーキテクチャの決定に影響を及ぼす諸要素と、アーキテクチャそれ自体に他ならない。
- 複数のビューが取り上げられた場合、設計担当者はビュー間の関連性に注目すべきであると判断していることになる。
「ユースケース・ビュー」で言及すべきこと
アーキテクチャ上、重要な振る舞いや操作についてのユースケースやシナリオやリスクを記述する。アーキテクチャ設計は内部構造だけを問うデザインではない。外部から観たシステムの振る舞いもインターフェイス仕様という意味で重要な要素となる。したがってこのビューでは、内部構造を決定する振る舞いやリスクに対応したユースケースを中心に列挙する。
ただし、ソフトウェア要求定義における「問題」に対応するユースケース・モデルが、そのままコアとなるアーキテクチャのインターフェイスの表現にも活用できる場合は、ソフトウェア要求定義書で掲載したユースケース図を再掲しても良い。
「ユースケース・ビュー」の一例
アーキテクチャを中心に考えた場合、重要な振る舞いや操作についてのユースケースやシナリオやリスクを記述していく。ただし、本設計ではソフトウェアやアプリケーションの構造と機能を記述することを主題としているため、ビジネスや運用フローまで視野に入れた全体のユースケース・モデリングについては割愛する。コアとなるアーキテクチャとの関連から協調すべきユースケース・モデルは、以下のようになる。
「論理ビュー」で言及すべきこと
コアとなるアーキテクチャとその周辺に位置するコンポーネント・アーキテクチャに関して、詳細クラス図を記述することが、この項目の主目的となる。上述した共通性／可変性分析などによって発見された抽象クラスや具象クラスについて、その静的構造をモデリングした結果を記述すべきだろう。モデリングすべき内容には、コアとなるアーキテクチャに対応する最重要となるクラスと、そのクラスと関連するパッケージやサブシステムの構成が含まれる。
成果物となるのは、大方詳細クラス図であろう。しかしクラス図を載せただけでは、余程わかり易い命名でもない限りは、実装担当者には伝わらないかもしれない。最低限、クラス名、インターフェイス名、メソッド名、プロパティ名などを一覧で説明する表やメモ書きを付け加えると良いだろう。
「論理ビュー」の一例
「実装ビュー」で言及すべきこと
「実装ビュー」では、「論理ビュー」で記述したモデルを如何にして利用していくのかについて記述していく。一つの方法として推奨できるのは、「論理ビュー」で言及した詳細クラス図に対応した相互作用図を作画するという方法だ。クラス図をインスタンス化した状態でどのような手順でメソッドを呼び出すのかなどについて、シーケンス図やコミュニケーション図をはじめとした相互作用図などによって描写すると良いだろう。
「実装ビュー」の一例
「プロセス・ビュー」で言及すべきこと
「プロセス・ビュー」は必須で取り上げるべき項目ではない。アーキテクチャ設計の担当者が必要であると判断した場合のみ取り上げる。具体的には、システムの動作に並行性が存在する場合に「のみ」言及すべきビューとなる。例えばJavaScriptでイベントドリブンな処理が頻発するようなシステムを設計する際には、このビューを取り上げることになる。
システムの動作の並行性を描写する上で有用となるのは、アクティビティ図やステートマシン図、あるいはタイミング図であろう。「ガード条件」や「トリガー」によって、イベントに駆動された処理を視覚化していくことになる。
「配置ビュー」で言及すべきこと
この項目もまた必須で取り上げるべき項目ではない。システムが複雑高度に分散している場合に「のみ」言及すべきビューとなる。例えばアーキテクチャ・パタンのMaster-Slave Patternのようなノウハウを採用することでサーバが分散することが予測される場合には、コンピュータのリソース状況を取り扱うことが求められるだろう。例えばUMLのシーケンス図やアクティビティ図、配線図、タイミング図などが、この場合に有用になる。
「データモデル」で言及すべきこと
この項目では、概念クラス図やER図などによって、データストアを設計していく。巷に散見されるように、MySQLのテーブル定義書やMongoDBのJSON構造などを取り上げることになる。
「非機能要求」で言及すべきこと
非機能要求は、脆弱性対策や負荷対策、性能などといった機能要求としては言及されていないが、システムの保守運用においては必要とされる項目を列挙していく。例えば負荷対策においては、どのような観点で過負荷テストを実施して、どのような条件を満たせば過負荷に耐久し得ると見做すのかについて、予め明示しておくことになる。
「開発の構成」で言及すべきこと
「開発の構成」では、開発プロジェクトの要因や条件を列挙していくことになる。例えば「制作フェーズ」におけるアサインメンバーの実装担当区分や「移行フェーズ」におけるリリースすべき文書を明示していく。改修するコードの保守やレビュー体制などについても明確化しておく。過負荷テストなどで他所のツールを利用する場合には、そのツールの公式の情報源なども記載しておく。
まとめ
以上のように、アーキテクチャ設計では、基本的にソフトウェア要求定義で取り上げた「問題」の再設定から始まる。この問題設定は、コアとなるアーキテクチャからの「逆算」によって実施していく。コアとなるアーキテクチャは、共通性／可変性分析などのような分析によって抽出していく。
コアとなるアーキテクチャを特定できたならば、まずはそのコンポーネント・アーキテクチャとその周辺のコンポーネントとの関連や全体像を俯瞰するために、コンポーネント図を作画してみよう。その上で、コアとなるアーキテクチャを「逆算」していた際にイメージしていた抽象クラスや具象クラス、あるいは公開インターフェイスなどのようなサブセットをより明瞭に視覚化できるようにしておく。
全体像を俯瞰できたならば、「4+1ビュー」の設計観点によって、コアとなるアーキテクチャを中心として、クラス設計やシーケンス設計を実践する手筈が整う。コアとなるアーキテクチャとその周辺の静的構造を問う「論理ビュー」や、その動的構造をより明確化できる「実装ビュー」に関しては、必須で取り上げて詳述していく必要がある。
こうしたコアとなるアーキテクチャを中心とした設計、すなわちアーキテクチャ・セントリック・デザインは、「データモデル」や「非機能要求」や「開発の構成」よりも優先されなければならない。コアとなるアーキテクチャを特定しないことには、「問題」に対応した「問題解決策」を展開できないからだ。「問題」に対応しない「問題解決策」を前提として、脆弱性対策や負荷対策などを講じたところで、顧客もエンドユーザも満足はしない。アーキテクチャ設計の担当者は、常に「問題」との関連から「問題解決策」として機能する「システム」を見極めなければならない。
（サンプル）既存トラッキングシステムのファーストパーティクッキー対応に関するアーキテクチャ設計書
- 問題設定
- アーキテクチャの決定
- システムの構成
- 設計の観点
- 4+1ビューに関する注意点
- ユースケース・ビュー
- 論理ビュー
- 実装ビュー
- プロセス・ビュー
- 配置ビュー
- データモデル
- 非機能要求
- 開発の構成
以上の項目について、以下より詳述していく。
問題設定
- ソフトウェア要求定義書（サンプル）によれば、次の機能が実装されなければならない。
- 計測タグ発行機能
- 計測タグのファーストパーティクッキー埋め込み機能
- 計測タグのファーストパーティクッキー参照機能
- 計測タグの成果発生可否判定機能
- トラッキングシステムの管理画面における計測機能
- しかし、既存のトラッキングシステムを視野に入れた共通性／可変性分析を実施するなら、「可変」となるのは、本来サードパーティークッキーを前提に処理していた部分に限定される。
- したがって、本開発プロジェクトで解決すべき問題となるのは、サードパーティークッキーを前提とした処理部分からファーストパーティクッキーを前提とした処理部分への切り替えが如何にして可能になるのかであるということになる。
アーキテクチャの決定
- 本開発プロジェクトにおけるコアとなるアーキテクチャは、サードパーティークッキーとファーストパーティクッキーの切り替え処理を備えた計測タグ発行機能に他ならない。
システムの構成
設計の観点
4+1ビューに関する注意点
- 設計担当者が必要と考えるビューのみに言及するため、製作すべきプログラムの全てを網羅することは最初から意図していない。
- このビューの絞り込みにおいて重要視しているのは、アーキテクチャの決定に影響を及ぼす諸要素と、アーキテクチャそれ自体に他ならない。
- 複数のビューが取り上げられた場合、設計担当者はビュー間の関連性に注目すべきであると判断していることになる。
「ユースケース・ビュー」の一例
アーキテクチャを中心に考えた場合、重要な振る舞いや操作についてのユースケースやシナリオやリスクを記述していく。ただし、本設計ではソフトウェアやアプリケーションの構造と機能を記述することを主題としているため、ビジネスや運用フローまで視野に入れた全体のユースケース・モデリングについては割愛する。コアとなるアーキテクチャとの関連から協調すべきユースケース・モデルは、以下のようになる。
論理ビュー
実装ビュー
サンプルについての補足
「データモデル」、「非機能要求」、「開発の構成」に関しては、RUPのアーキテクチャ設計に特有の概念ではないため、ここでは割愛する。
参考文献
- Coplien, J., Hoffman, D., & Weiss, D. (1998). Commonality and variability in software engineering. Software, IEEE, 15(6), 37-45.
- Shalloway, A., & Trott, J. R. (2004). Design patterns explained: a new perspective on object-oriented design. Pearson Education.