ソフトウェアアーキテクチャの文書化というのは、企業のアプリケーション開発プロセスにおいて重要である。プロジェクトにおけるアーキテクチャの文書化のニーズを理解する上で重要なことは、アーキテクチャの文書化がプロジェクトのライフサイクルにおいてどんな役割を果たすのか理解することだ。プロジェクトにおいて、アーキテクチャドキュメントを作成する根本的な理由は、コミュニケーションと分析と記録のためである（例えば、ある決定をドキュメントに記録しておくと、時間が経過しても失われることはない）。プロジェクトで作成するアーキテクチャドキュメントの量と種類は、そのプロジェクトで作成するプロダクトのコミュニケーションおよび分析のニーズを反映したものにするべきである。
アーキテクチャドキュメントは、プロジェクトからマネジメントへ、アーキテクトや主任設計者から開発者へ、プロジェクトから時を超えて将来の保守管理者や開発者へ、コミュニケーションするために使われる。このシンプルな一文から、3つの質問が浮かび上がるだろう。そして、その質問への回答がドキュメントの量と種類を決めるのに役立つ。プロジェクトはどれくらい監督されているのか？ そのプロダクトを開発するのにどれくらいの開発者がいて、彼らにはどれくらいのスキルがあるのか？ そのプロダクトをどれくらい長生きさせるつもりなのか？ 監督すればするほど、マネジメントに伝えるためのドキュメントのニーズは高まる。開発者がいればいるほど、またそのスキルが低ければ低いほど、開発者にアドバイスするためのドキュメントのニーズは高まる。プロダクトが長生きすると想定されているほど、そのプロダクトの将来の開発者に伝えるためのドキュメントのニーズは高まる。
アーキテクチャドキュメントによるコミュニケーションには、マネジメントや開発者に伝えることと、時を超えて（プロジェクトのライフサイクルを超えて）伝えることが含まれる。そして、分析のニーズは、パフォーマンス、セキュリティ、信頼性といったプロダクトの品質を決定づける内部要因によって、あるいは、要件に基づいた規制や標準へのコンプライアンスを決定づける外部要因によってもたらされる。
この仮想パネルでは、一流のソフトウェアアーキテクチャ専門家から、ソフトウェアアーキテクチャの文書化の重要性、特に、アジャイルソフトウェア開発環境においてアーキテクチャを文書化する方法について調べていく。
質問に答えてくれたパネリスト:
Len Bass氏, SEI (Software Engineering Institute)のテクニカルスタッフのシニアメンバ、Software Architecture in Practiceと、もうすぐ第2版の出る "Documenting Software Architectures: Views and Beyond"の共著者。
Grady Booch氏, IBMフェロー、 Webサイト"Handbook of Software Architecture"の著者
Paulo Merson氏, SEI (Software Engineering Institute)のテクニカルスタッフのシニアメンバ、"Documenting Software Architectures: Views and Beyond"の共著者
Eoin Woods氏, Barclays Global InvestorsのApplication Architectureグループヘッド、"Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives"の共著者
SCRUM、XP (eXtreme Programming)、Kanbanなど、アジャイルやリーンと呼ばれるソフトウェア開発手法を使っているチームでは、ソフトウェアアーキテクチャの文書化はどのような役割を果たすのでしょうか？
Len氏: 開発手法が変わったからといって、アーキテクチャを文書化する目的が変わるわけではありません。ドキュメントは単にコミュニケーションのための手段ではありません。SCRUMやXPといったアジャイル開発手法では、直接対話することで一部のドキュメントのニーズを置き換えています。でも、設計判断に関する詳細なコミュニケーションを目的としたドキュメントのニーズは、直接対話では置き換えることはできません。設計判断といったものは、ミーティングの場で伝えて理解してもらうのが難しいためです。時間が経過してからのコミュニケーションやマネジメントとのコミュニケーションというのは、アジャイルでは扱われていません。確かに、アジャイルでは直接的なコミュニケーションをするため、一部のドキュメントのニーズは低くなるでしょう。でも、それだけのことです。
Grady氏: 儀式度の高い手法を使っているチームではなおさら役割は同じでしょうね。結局のところ、ソフトウェア中心のシステムのアーキテクチャを文書化することには、複数の目的があるということです。チームが重要な設計判断を理解できるようにするため、部内の記憶を体系化しておくため、イテレーションごとに意識的に管理しておく最も重要な成果物とするため、など。アジャイルのような軽量な開発手法では、アーキテクチャドキュメントは、これから設計するシステムではなく、すでに構築したシステムを反映したものとして使われることも多いです。
Paulo氏: 一般的にソフトウェアアーキテクチャの役割とは、不明確で揺れ動くことの多い要件と実際に動作する実装との間の橋渡しをすることです。アーキテクチャドキュメントには設計判断を記録しておきます。これは（最初に）実装を導くための道具であり、想定した解決策が正しい判断であるか評価するために使えます。また、仕事の割り当てやトラッキングにも役に立つでしょう。
では、アジャイルではどうでしょう？ アジャイル開発はアーキテクチャの文書化とは対極にあると考えるのは、まったくの間違いです。アジャイルが目標にしているのは、設計を避けることではなく、BDUF ("big design up front")（事前に大規模な設計を行うこと）を避けることです。広範囲にわたる大規模なアーキテクチャ戦略は事前にやっておきますが、それ以外の設計判断は本当に必要になるまで遅らせるのです。例えば、データモデルについては、後から大きな変更が起こらないよう事前にしっかりと議論しておくことが多いです。それに対して、次回のスプリントでやる機能のシーケンス図やインターフェイス定義は、実装する前に文書化することになるでしょう。
アジャイル開発者は設計スキルをもっていることが期待されており、アジャイルアーキテクトはコーディングスキルをもっていることが期待されています。そのため、設計判断に関するコミュニケーションは、短時間で集中して行われます。実際にはどうなるのでしょう？
- 図は多くて、文章は少ない。
- コーディングへ移行するのに十分な設計情報が含まれている。
- 参照アーキテクチャを表すダイアグラム（あるいはパターンの適用方法)に注力する。そして、似たような機能やフローになる部分の設計は、参照設計から推測できるので簡潔に文書化する。
- きちんとした総合的なダイアグラムというよりも、スケッチに近いものになる。
- 設計ダイアグラムは更新されるのではなく消される。時代遅れになった設計をそのまま残しておくよりもまし。（私の場合は通常、以下のダイアグラムのように、見てすぐわかる印を付けるようにしています。)
Eoin氏: 当たり前のように聞こえるかもしれませんが、実際のところ、この質問の回答はチームやプロジェクト、それらが置かれている状況によって違ってきます。アーキテクチャ記述はどんなものであれ、特定の目的のため、特定の読者のために作られる必要があります。そうでなければ、そんなものを作るのは時間のムダです。読者が作成者自身だけの場合もあります（分析のためや、単なる補助記憶として）。でも、重要なアーキテクチャ記述であるなら、それに関心のある人は大勢いるはずです。
個人的には、アジャイル開発とソフトウェアアーキテクチャとの間に、そんなに緊張があるのを見たことはありません。しかし、すべての人がそういうわけではないでしょう。おそらく私は幸運だったのだと思います。私の経験上、明確で簡潔なアーキテクチャ記述というものは、プロジェクトが進捗するにつれて徐々に作られていくもので、アジャイルであろうがなかろうが、ソフトウェア開発チームにとって役立つものです。
すぐれたアーキテクチャ記述というのは、コードからははっきりとわからない設計の側面（デプロイメント設計、外部インターフェイス、システムモニタリングのアプローチ）について記録したもので、そのシステムが非機能要件（通常、HA、セキュリティ、パフォーマンス要求などを含む）をどのように満たすのか説明するものです。もし、だれもこうした問題に関心がないのであれば、アーキテクチャを記述しておく必要はありません。でも、そんなことはまずないと思います。
ここで重要なことは、アーキテクチャ記述にはさまざまな形式がありますが、アジャイルチームで仕事をしているときにはたいてい、分厚いドキュメントは最も効果が低いということです。重要になるのは、アーキテクチャを記述するうちに、まとめられ獲得された知識や、そこで実施した分析なのです。使っているドキュメントテンプレートではありません。アーキテクチャ記述は、効果的なコミュニケーション媒体になるべきものです。一冊にまとまとめられた重厚なものよりも、Wiki、モデル、データベース、スプレッドシート、的を絞った簡潔なドキュメントの集まりといったものの方が、アーキテクチャ設計に関する情報を記録してコミュニケーションをするのに、ふさわしい方法になるでしょう。
DSL（ドメイン固有言語）に基づくアプリケーションのアーキテクチャを文書化するとき、したがっておくべき特別なアーキテクチャの文書化パターンというものはありますか？
Eoin氏: 私自身まだプロダクションシステムにDSLを使ったことはないのですが、実装技術を変更することが、アーキテクチャを文書化する一般的なアプローチにそれほど影響を及ぼすとは思えません。依然として、アーキテクチャドキュメントには、システムのコンテキスト、機能構造、デプロイメント環境、情報構造、運用環境などを定義して、非機能要件がどのように満たされるのか説明しておく必要があります。各セクション（または「ビュー」）で設計を記述するために使う基本要素は、利用している技術によって違ってくるかもしれませんが、そうだとしても内容については同じことを記述する必要があります。
Len氏: DSL言語、プロファイルやステレオタイプ、追加のモデリング言語、メタモデルといったものによって、表記法が定義される（そうでないものもあります）ということは、ドキュメントをより明確にするのに役立つと思います。ドキュメントの読み手と書き手の双方が表記法を理解していれば、お互いの労力を減らせるでしょう。
Grady氏: 特別なものというのはないでしょうね。ソフトウェアアーキテクチャを文書化するのにどんなアプローチをとろうとも、その本質は、ステークホルダを特定して、ステークホルダが関心のあるビューを特定することです。必要なビューを決定することは、ドメインや開発の文化によります。
Paulo氏: アーキテクチャドキュメントは、複数のシステム構造を示す複数のビューによって構成されます。DSLを使っているということは、ビューの一部、例えば、デプロイメントビューやランタイム（別名コンポーネント&コネクタ、プロセスなど）ビューなど、には影響を与えないでしょう。アーキテクチャのモジュール（別名コード）ビューでは、DSLがよく利用されています。このビューは、どんな実装ユニットがあり、それらがモジュールやサブモジュールにどうまとめられているのか、各種関係や依存関係について示しています。どんなビューであっても、表現されている要素のタイプを特定することが非常に重要です。DSLを使うことで、要素や関係に対する明確なタイプ付けを強制することができます。特に、ソリューション全体でDSLを他の言語と組み合わせて使うときには、アーキテクチャドキュメントにおける要素のタイプを特定することが重要になります。実際に、どんな場合であっても、必ずダイアグラム要素は必要になるでしょう。ですから、異なる要素のタイプには異なる形や色を使って、楕円に対して四角が何を意味しているのか、ドキュメントに示しておくのです。線や矢印を区別することも忘れてはいけません。DSLはたいていの場合、自動化ツール、ライブラリ、コードジェネレータといったものを備えています。そのため、実装スコープとツールが提供するものを明記しておくことも重要です。コンテキストダイアグラムが役に立つでしょう。コードジェネレータを使うときは必ず、どんなランタイム要素が生成されるのか、それらにはどんな性質があるのか理解しておきましょう。シングルプロセス／スレッドなのかどうか、どんな通信プロトコルが使われているのか、どんなデータストレージの仕組みが使われているのかなどを調べておきましょう。これらは、セキュリティ、パフォーマンス、インターオペラビリティといった品質要件を評価するときに関係してくるためです。
以前、MicrosoftのVisual Studioを使ってモデリングDSLを定義するデモを見たことがあります。それはかなり見栄えのよいものでした。でも、たとえDSLを使っていたとしても、UMLのような汎用モデリング言語を使って設計を文書化することができます。汎用のUMLシンボルから派生したドメイン固有のシンボルを定義するために、UMLプロファイルがよく使われています。
OSGiのような新しい動的Javaモジュール仕様がソフトウェアアーキテクチャの文書化にうまく合うのはどんなところでしょうか？
Paulo氏: ソフトウェアアーキテクトは普通、アーキテクチャドキュメントのモジュールビュー（別名コードビュー）に注目します。彼らは、実装ユニットがパッケージやサブパッケージにどのようにまとめられるのか、お互いのモジュールにどんな依存関係があるのか、どんな階層構造やレイヤ構造にまとめられるのか、具体的なトランザクションにおけるメッセージの流れがどうなるのか、といったことを説明するのに時間を費やしています。もちろん、こうしたアーキテクチャのコードビューを作ることも非常に重要なことですが、ランタイムやデプロイメントが軽視されてしまうことが多いのです。このようなモジュールビュー以外のビューは、ランタイム環境やプラットフォームインフラストラクチャ、コンポーネントモデルなどをきちんと理解するために必要になります。ランタイムビューは、実装ユニットが、スレッドやプロセス、Servlet、DLLなど、コンポーネントの観点から何になるのかを示しています。また、データリポジトリ、インフラストラクチャサービス、外部サービス、通信メカニズム（例えば、JMS、SOAP、HTTP、ローカルあるいはリモートメソッド呼び出しなど）についても示しています。ランタイムビューを使うことで、パフォーマンス、セキュリティ、可用性といった、パッケージ図やクラス図を見るだけでは評価するのが難しいランタイム特性について推測できるようになります。デプロイメントビューは、ハードウェアインフラストラクチャを示しており、デプロイメントされるものがどのようにまとめられ、デプロイされるのかを説明しています。こうしたビューは保守性、パフォーマンス、セキュリティなどの特性について推測するのに役に立ちます。
では、あなたの質問に答えることにしましょう。もしあなたがOSGiアプリケーションを設計しているのであれば、OSGiランタイム環境にどんなコンポーネントがあるのかを理解し、それらのライフサイクルについて理解しておかなくてはなりません。私は一度だけOSGiを使ったことがありますが、それはEclipseプラグインの開発でした。この場合、manifestファイルを作る必要があることを除いて、OSGiフレームワークは見えなくなっています。でも、OSGiアプリケーションのアーキテクトに質問させてください。
- アーキテクチャドキュメントには、デプロイ可能な各バンドルにはどのJavaパッケージ／クラスが入るのか明記されていますか？
- ランタイムにおいて、各バンドルはスレッドに対応しているのでしょうか？ それとも、バンドル内のそれぞれのサービスは別スレッドになっているのでしょうか？
- いずれにせよ、ドキュメントには、こうしたスレッドについて明記されていますか？
- サービスへの呼び出しごとに新しいスレッドインスタンスが作られるのでしょうか？例えば、HTTPリクエストを解決するたびに、同一Servletのスレッドインスタンスが作られるのでしょうか？
- 複数のバンドルで使われるライブラリのjarファイルをデプロイしたいとき、それをどこに置くべきか、ドキュメントに明記されていますか？
- OSGiのpub-subメカニズムを通して送られるイベントは、同期ですか非同期ですか？
- ランタイムビューにおいて、使われている呼び出しやプロトコル（例えば、HTTP）のタイプが区別されていますか？
- ドキュメントには、確実に可用性、パフォーマンス、セキュリティに影響を及ぼす、サービスレジストリとのやり取りが明記されていますか？
このように、解答の半分はコンポーネントのタイプ、通信メカニズム、ランタイム環境のインフラストラクチャサービスを反映したアーキテクチャのランタイムビューおよびデプロイメントビューを作ることです。
もう半分は可変性についてです。私たちのアーキテクチャドキュメントのテンプレートには、そのためのセクションが1つあります。可変性ガイドというセクションでは、システムを設定可能にするための仕組みについて説明します。以下のような仕組みがあるでしょう。
- コンポーネントの置き換え（同一インターフェイスを提供する）
- コンポーネントの複製
- コンポーネントの追加オプション（プラグイン、アドオン）
- ビルド時に埋め込む設定
OSGiのようなフレームワークを使うと、こうした仕組みがすぐに使えるようになります。アーキテクチャのランタイム図は、どんなコンポーネントがあるのかという観点では変わるでしょう。アーキテクチャを文書化するときには、どのコンポーネントが変更可能か、どんなオプション（あるいは、設定）があって、それぞれどんな効果があるのか、どんな状況にどんなオプションを選択すればよいのか、それぞれのオプションはいつ束縛されるのか（OSGiの場合はランタイム時になりますが、構築時やデプロイ時になることもあります）といったことについて、可変性ガイドに記述しておかなくてはなりません。
Eoin氏: システムのコンポーネント構造を、ランタイム時に（そして、設計時にも）もっと目に見えるようにするのはすばらしいことです。設計からコードへと移行するとき、私たちはこうした情報の多くを無駄にしているためです（そのために、アーキテクチャ記述が必要になるのです。先ほどの回答を参照！）。最近、OSGiを学んでいるところなのですが、OSGiはまさにこの問題を解決して、システムの機能的構造をさらに明らかにするのに役立つのではと考えています。それと同時に、OSGiのようなモジュール化技術は、実際に検討すべきニーズがたくさんあるときに、ある種のアーキテクチャ構造を明らかにするのに役立つのにすぎないのではないかとも考えています。そのため、OSGiを利用することで他にもいろいろな技術的利点があったとしても、アーキテクチャ記述を捨て去ることはできません。
Len氏: ソフトウェアアーキテクチャを文書化するための標準的なビューのひとつは、モジュール分解ビューです。このビューにおける各モジュールは、カプセル化のスコープを表現しています。OSGiというのはカプセル化のスコープを指定するひとつの手段であって、モジュール分解ビューにそのまま当てはめることができます。
Grady氏: OSGiはもともと、Kruchten氏が実装ビューと呼んでいたもの、すなわち、コンポーネントの物理的なパッケージに関心を払っています。こうしたパッケージはデプロイメントビューで提供されるもので、これらのコンポーネントが動作する物理的なトポロジーを表現しています。したがって、アーキテクチャの観点から見ると、OSGiは単なるひとつのパッケージング技術にすぎませんね。
"プロファイル" や "ステレオタイプ" といったUMLの機能は、ソフトウェアアーキテクチャの文書化にどのように役立つのでしょうか？
Grady氏: これらはUMLの拡張性の主要なメカニズムになっています。でも私の経験上、ソフトウェア中心のシステムの基本アーキテクチャを文書化するのは、基本のUML言語だけでほとんど十分です。
Paulo氏: UMLはもともとオブジェクト指向システムをモデル化するために作られました。それが今では、汎用のモデリング言語だと見なされています。つまり、たくさんの異なるものを表現するのに同じシンボルが使われています。例えば、DispatcherというUMLコンポーネントは、Java EEソリューションではServletを表現していたり、OSカーネルではスレッドを表現していたりします。ステレオタイプを定義すると、UMLシンボルを特殊化できるようになります。そのため、コンポーネントがServletだとわかっているなら、<<servlet>> とステレオタイプ化しましょう。ステレオタイプを正しく使えば、UMLダイアグラムはもっと表現豊かになります。UMLには標準のステレオタイプがいくつかありますが、自分のステレオタイプを自由に作ることもできます。
UMLプロファイルというのは、ひとまとめにする意味のあるUMLステレオタイプのグループにすぎません。Java EEのプロファイル、.NETのプロファイル、SOAのプロファイル、システム工学のプロファイルなどがあります。こうしたものを再利用したり、自作のステレオタイプやプロファイルを使うのはよいことだと思います。
Eoin氏: 簡単に言えば、ライフセーバーだと思っています。UML2の拡張性は強みであり、UMLをさまざまな用途に使えるようにする手段のひとつです。まだ活用できている人はほとんどいませんが、最近のUMLツールはようやくこの拡張性に追いついてきて、自分が使っている言語にあったステレオタイプやプロファイルを使うことができます。うまくやると自分の目的に合ったUMLのバージョンを作ることができます。特殊化することによって、アーキテクチャで使いたい構成要素のタイプをうまく表現できるようになるのです。結局のところ、これはUMLベースのアーキテクチャ記述言語になります。これは既存のツールでもサポートできるため、多くの研究ベースのADL（xADL、Acme、Darwinなど）を導入する上で大きな障壁となっているひとつの問題を克服することができます。
SOAにおけるサービス設計のためのUMLプロファイルや、メタモデルを記述するサービス指向アーキテクチャモデリング言語（SoaML）といった新しい仕様がありますよね。SOAやクラウドコンピューティングアーキテクチャモデルを利用したアプリケーションでは、アーキテクチャの文書化はどのようにすべきでしょうか？
Eoin氏: SOAとクラウドコンピューティングは（たとえ一方がもう一方をより簡単に利用できたとしても）比較的独立した技術であると私は考えています。SOAというのは、システムを疎結合なサービスの集合体として構築するアーキテクチャスタイルです。クラウドコンピューティングというのは、システムをホストするマシンのプロビジョニング、運用、管理を単純化するために、ランタイムプラットフォームを仮想化するデプロイメントモデルです。 これらはいずれも、場所に依存しないという点で関連がありますが、それぞれ異なる側面を解決するものです。DSLと同様、どちらの技術も、アーキテクチャ記述で記録する必要があるもの、あるいは、それらを記録する方法といったものを根本的に変えるとは思いません。でもこれまで述べたように、（SoaMLのような）モデリング言語の特殊化は、特定のアーキテクチャをもっとわかりやすく文書化するのに確かに役立つでしょう。
Paulo氏: SOAは、SOAP Webサービス、REST、メッセージングシステム、BPEL、ESBといったさまざまな技術を利用して実現されるアーキテクチャスタイルです。実際にSOAベースのアーキテクチャを作るときには、どんな技術を利用しようとしているのか特定する必要があるでしょう。例えば、SOA設計におけるサービスプロバイダのコンポーネントが、汎用の <<participant>> ではなく <<dll>> や <<servlet>> としてステレオタイプ化されていると、読者にとって洞察力に富んでいると思います。
考えてみてください。ソフトウェア開発者はますます増えていく新しいプログラミング言語、スクリプティング言語、技術、開発フレームワーク、設計パターン、IDEやプラグイン、モデリングツール、開発テクニックに遅れないよう、ついていく必要があります。私はソフトウェア開発者として、シンプルですでになじみのあるソリューション要素に対応したステレオタイプがあるのであれば、UMLプロファイルを学びたいと思います。
SoaMLのような技術にとらわれないUMLプロファイルは、幅広いアーキテクトにアピールするのは難しいでしょうね。とはいえ、あなたが使っているモデリングツールがこのプロファイルをサポートしているなら、このプロファイルに精通しておくことも確かに重要なことでしょう。
UMLプロファイルを使っても使わなくても、SOA、クラウドコンピューティング、OSGi、ピアツーピアなどのアーキテクチャスタイルを使ったアプリケーションを適切に文書化するときに重要なことは、そのスタイルに特有な要素および関係のタイプを明記するようなアーキテクチャビューが含まれていることです。
Grady氏: 確かに、重要な設計判断が何であるかを決定することが、最も重要な問題になります。複数のサービスを利用するようなシステムでは、（単なる2点間のサービスではなく）メッセージ自体の設計が最も重要になります（忘れられていることが多いのですが）。ちなみに、クラウドコンピューティング（これは今や技術用語というよりもマーケティング用語になっていますが）の場合には、デプロイメントビューの要素にもっと注意を払うとよいでしょう。
ソフトウェアアーキテクチャを文書化するとき、ソフトウェアアーキテクトが覚えておくべきベストプラクティスや「わかった！」ということには、どんなものがありますか？
Len氏:
- ソフトウェアアーキテクトは、ドキュメントを作成する目的を肝に銘じておかなくてはなりません。過剰なドキュメントや過少なドキュメントは、ドキュメントの目的を見失っているサインです。
- 時間が経過したときのコミュニケーション手段としてドキュメントを利用する場合には、プロジェクト自体はその第一決定者とはならないでしょう。ほとんどのプロジェクトメンバは保守や機能強化に関わることはなく、ドキュメントの有無には無関係になるためです。
- Wikiはアーキテクチャドキュメントの効果的なメディアであることがわかっています。
Grady氏: 覚えておくべきことが3つあります。文書化しすぎてはいけません。イテレーションごとにドキュメントを有効なものにしましょう。コードからは簡単にはわからないビューや分野横断的な懸念事項に注意を払いましょう。
Paulo氏:
- アーキテクチャを複数のビューを使って文書化しましょう。
- ダイアグラムには必ず凡例を入れましょう。
- デザインパターンやアーキテクチャパターンを使っているのであれば、そのことが読者にわかるようにしましょう。
- テンプレートにしたがいましょう。
- ステークホルダにとって役立つドキュメントにだけ時間をかけましょう。
- 重要な設計判断には、その根拠を明記しておきましょう。
- 作成したドキュメントはレビューするようにしましょう。
Eoin氏: まず、SEIの "Documenting Software Architectures" という本には、非常にすばらしい7つの「健全なドキュメントのためのルール」があることを覚えておきましょう。これは技術レポート (SEI-2000-SR) のひとつとして公開されており、SEIのWebサイトから利用できます。
この質問に完全に答えるにはちょっとした一冊の本が必要になると思うのですが、私がソフトウェアアーキテクチャを文書化するときに覚えておくべき重要なことだと思っているものを、いくつか挙げておきましょう。
- 明確な目的を頭に置いて文書化しましょう。
- 明確な読者に向けてアーキテクチャを記述しましょう。
- たとえ抽象的にしているところでも、記述内容は正確にしましょう。
- 使用する表記法を注意深く定義しましょう。そうすれば、他の人も明確に理解できるようになります。
- 備忘録としての役割を果たして記述内容の指針となるような、ソフトウェアアーキテクチャのビューポイント定義を使いましょう。
- ドキュメント自体が目的にならないようにしましょう。重要なのは、あなたが実現するプロセス、内容、コミュニケーションなのです。
- 絶えず正確さや有用さをレビューしながら、アーキテクチャ記述を反復的に作成していきましょう。
企業におけるソフトウェアアーキテクチャドキュメントへの取り組みは、現在の経済および市場において、企業にどう役立つのでしょうか？
Grady氏: これはアーキテクチャを成果物として扱うことの本質でしょう（まさにこの話題について、IEEE Softwareの私のコラム「On Architecture」に数ページの記事を書きました。）。
Paulo氏: Steve McConnell氏、Barry Boehm氏らの調査によると、要件やアーキテクチャに由来する欠陥は、修正するのにかなりのコストになるようです。言い換えると、健全なアーキテクチャは企業に利益をもたらすということです。ところで、ソフトウェアアーキテクトが経験豊かで、パターン、現在の技術、モデリングツール、言語についてすべて知っているかどうかは問題ではありません。というのも、こういう人たちは巧妙な設計を作り出すのですが、開発者がそれを理解できなくて、プロジェクトはすぐれたアーキテクチャの恩恵を得られないためです。ソフトウェアドキュメントはアイデアをやり取りするのに失敗しやすいものです。ひとつの理由は、ソフトウェアエンジニアは普段、技術的なドキュメントを書く訓練を受けていないためです。すぐれたアーキテクチャドキュメントがあれば、以下を実現することができます。
- アーキテクチャ評価
- ソフトウェア再利用
- うまくいく調達計画とRFP
- プロジェクト管理タスク（見積り、割り当て、トラッキング）
要するに、適度に詳細な（詳細すぎない）すぐれたドキュメントがあることは、ソフトウェアプロジェクトが成功するチャンスを高めるということです。
Eoin氏: アーキテクチャ記述と継続的なアーキテクチャレビューが賢明になされていると、構築しているシステム（また、実際にすでに存在しているシステム）がもっと目に見えるようになり、組織が次のような質問に回答するのに役立ちます。
- システムには適切な機能がありますか？（個別に、また全体として）
- システムに重複はありますか？
- システムは一貫した方法で構築されていますか？
- 過度の高度化、柔軟性、互換性、セキュリティ、その他コストになるシステム品質というものはありますか？
- 柔軟性のないシステムになっていて、後から発展させるには多大なコストが必要になりますか？
- 何かコストになるような間違いをしようとしていませんか？
Len氏: ソフトウェアアーキテクチャを文書化することには、これまで説明してきたような目的があります。企業がプロジェクトを監視したい、開発者間のコミュニケーションを高めたい、時間が経過してもコミュニケーションできるようにしたい、設計を分析したいのであれば、アーキテクチャを文書化することは企業にとって役立つでしょう。
ソフトウェアアーキテクチャの文書化の将来はどうなると思いますか？
Eoin氏: 将来、ほとんどソフトウェアアーキテクチャドキュメントが必要なくなることを願っています。なぜなら、アーキテクチャというのは、コードや動作するシステムの中に見ることができるためです。現在、アーキテクチャドキュメントを必要としている理由のひとつは、どんな技術を使おうともアーキテクチャ構造を直接表現できるような方法がないためです。私はアーキテクチャ構成概念を第一級の実装構造だと見なすのが好きです。アーキテクチャドキュメントは単に構造を記録するものではなく、判断や根拠、分析を記録するよう発展させることができます。この境地に到達するために、DSLやADL（アーキテクチャ記述言語）の分野において、記述言語が改良されて、動作するシステムに情報をそのまま埋め込めるよう研究が進んで、方向性を示してくれることを望んでいます。
Paulo氏: ソフトウェアアーキテクチャというのは、まだかなり新しい分野です。アーキテクトが、これまで一緒に仕事をしたことがない開発者でもすぐに理解できるアーキテクチャドキュメントを作れるようになるには、長い道のりが必要です。新しいアーキテクトがそこへ到達するには、現場でのトライ＆エラーではなく、学校でソフトウェアアーキテクテチャを学ばせる必要があります。教えるべきことには、他の人のために適切にソフトウェアアーキテクチャを表現する方法も含まれます。すぐれたソフトウェアアーキテクチャ教育に向けた重要な取り組みとして、"Handbook of Software Architecture" におけるGrady Booch氏の活動や、SEIで開発された出版物やカリキュラムがあります。
Grady氏: 現在、TOGAF, NEA, DoDAF、MoDAF、FSAM、Zachmanなど、アーキテクチャのフレームワークや手法に対してかなりの労力が注がれています。こうしたフレームワークや手法について、活発な議論がなされているというのはよいことですが、次第に淘汰されて単純化されていくことを期待しています。
Len氏: 理想的な開発環境というのは、ただボタンを押すだけでドキュメントが出来上がるような環境でしょう。これには、開発、要件管理、プロジェクト管理のための統合環境が必要になります。これを実現するにはまだ時間がかかるでしょうが、追い求めるだけの価値のある目標だと思います。