ソフトウェアシステムアーキテクチャ構築の原理 第2版
SB Creative
著者：Nick Rozanski、Eoin Woods
訳者：牧野祐子
監修：榊原彰
日本語第2版への序
第2版の序
第1版の序
1 概論
1.1 ステークホルダとビューポイントおよびパースペクティブ
1.2 本書の構成
1.3 本書が対象とする読者
1.4 使用している慣例
第1部 アーキテクチャの基本
2 ソフトウェアアーキテクチャの概念
2.1 ソフトウェアアーキテクチャ
2.1.1 システムの要素と関係
2.1.2 基本的なシステムの特性
2.1.3 設計と発展性の原理
2.1.4 システム特性と内部構成
2.1.5 ソフトウェアアーキテクチャの重要性
2.2 アーキテクチャ要素
2.3 ステークホルダ
2.3.1 個人、チーム、または組織
2.3.2 興味と関心事
2.3.3 ステークスホルダの重要性
2.4 アーキテクチャ記述
2.5 中心的概念間の関係
2.6 要約
2.7 参考文献
3 ビューポイントとビュー
3.1 アーキテクチャビュー
3.2 ビューポイント
3.3 核となる概念間の関係
3.4 ビューポイントとビューを使用する利点
3.5 ビューポイントの落とし穴
3.6 ビューポイントカタログ
3.6.1 ビューポイント概観
3.7 要約
3.8 参考文献
4 アーキテクチャパースペクティブ
4.1 品質特性
4.2 アーキテクチャパースペクティブ
4.3 パースペクティブをビューに適用する
4.4 パースペクティブ適用の結果
4.4.1 洞察
4.4.2 改善
4.4.3 アーティファクト
4.5 核となる概念間の関係
4.6 パースペクティブを使用する利点
4.7 パースペクティブの落とし穴
4.8 パースペクティブをビューと比較する
4.9 パースペクティブカタログ
4.10 要約
4.11 参考文献
5 ソフトウェアアーキテクトの役割
5.1 アーキテクチャ定義プロセス
5.1.1 アーキテクチャ定義は単なる設計ではない
5.1.2 要求分析とアーキテクチャ定義の境界
5.1.3 アーキテクチャ定義と設計の境界
5.2 アーキテクトの役割
5.2.1 アーキレクチャ的リーダーシップ
5.3 核となる概念間の関係
5.4 アーキテクチャの専門化
5.5 組織コンテクスト
5.5.1 ビジネスアナリスト
5.5.2 プロジェクトマネージャ
5.5.3 設計の権威
5.5.4 テクノロジースペシャリスト
5.5.5 開発者
5.6 アーキテクトのスキル
5.7 アーキテクトの責務
5.8 要約
5.9 参考文献
第2部 ソフトウェアアーキテクチャのプロセス
6 ソフトウェアアーキテクチャプロセス概論
7 アーキテクチャ定義プロセス
7.1 指針となる原理
7.2 プロセスの成果
7.3 プロセスコンテクスト
7.4 サポートアクティビティ
7.5 アーキテクチャ定義アクティビティ
7.6 プロセス終了基準
7.7 ソフトウェア開発ライフサイクルにおけるアーキテクチャ定義
7.7.1 ウォータフォールアプローチ
7.7.2 反復的アプローチ
7.7.3 アジャイル手法
7.8 要約
7.9 参考文献
8 関心事、原理、決定
8.1 問題重視の関心事
8.1.1 ビジネス戦略
8.1.2 ビジネス目標とビジネスドライブ
8.1.3 システムスコープと要求
8.1.4 ビジネス基準とビジネス方針
8.2 解決策重視の関心事
8.2.1 IT戦略
8.2.2 テクノロジー目標とテクノロジードライバ
8.2.3 テクノロジー標準とテクノロジー方針
8.3 その他の現実的な制約
8.4 妥当な関心事とは
8.5 アーキテクチャ原理
8.5.1 優れた原理とは
8.5.2 独自の原理を定義する
8.6 アーキテクチャ上の判断
8.6.1 アーキテクチャ上で重大な判断
8.7 原理を使って関心事と判断を結び付ける
8.8 チェックリスト
8.9 要約
8.10 参考文献
9 ステークホルダを特定して参加させる
9.1 ステークホルダの選出
9.2 ステークホルダのクラス
9.2.1 取得者
9.2.2 評価者
9.2.3 コミュニケータ
9.2.4 開発者
9.2.5 保守管理者
9.2.6 制作エンジニア
9.2.7 供給者
9.2.8 支援スタッフ
9.2.9 システム管理責任者
9.2.10 テスタ
9.2.11 ユーザ
9.3 実例
9.3.1 既製パッケージの配置プロジェクト
9.3.2 ソフトウェア製品開発プロジェクト
9.3.3 提携開発
9.4 代理ステークホルダ
9.5 ステークホルダグループ
9.6 ステークホルダの責務
9.7 チェックリスト
9.8 要約
9.9 参考文献
10 シナリオを特定して使用する
10.1 シナリオのタイプ
10.2 シナリオの用途
10.3 シナリオを特定して優先順位を付ける
10.4 シナリオをとらえる
10.5 何が良いシナリオを構成するか
10.6 シナリオを適用する
10.6.1 紙のモデル
10.6.2 ウォークスルー
10.6.3 シミュレーション
10.6.4 プロトタイプ実装テスト
10.6.5 完全なライブテスト
10.7 シナリオの有効活用
10.7.1 集中するシナリオセットを特定すること
10.7.2 異なったシナリオを使用すること
10.7.3 シナリオは早期に使用すること
10.7.4 システム品質シナリオの使用を含めること
10.7.5 障害時シナリオの使用を含めること
10.7.6 ステークホルダを緊密に参加させること
10.8 チェックリスト
10.9 要約
10.10 参考文献
11 スタイルとパターンを使用する
11.1 デザインパターンを導入する
11.2 スタイル、パターン、イディオム
11.2.1 アーキテクチャスタイル
11.2.2 ソフトウェアデザインパターン
11.2.3 言語イディオム
11.2.4 スタイルとパターンおよびイディオムを使用する
11.3 パターンとアーキテクチャ戦術
11.4 アーキテクチャスタイルの例
11.5 アーキテクチャスタイルを使用する利点
11.6 スタイルとアーキテクチャ記述
11.7 デザインパターンと言語イディオムを適用する
11.8 チェックリスト
11.9 要約
11.10 参考文献
12 アーキテクチャモデルの制作
12.1 モデルが重要な理由
12.2 モデルのタイプ
12.2.1 定性的モデル
12.2.2 定量的モデル
12.2.3 スケッチ
12.3 モデリング言語
12.3.1 アーキテクチャ記述言語
12.3.2 統一モデリング言語（UML）
12.3.3 実行可能なドメイン特有言語
12.3.4 その他のモデリング言語
12.4 効果的なモデルを作成するための指針
12.4.1 モデルに目的を持たせよ
12.4.2 モデルを読者に対応させよ
12.4.3 抽象化は慎重かつ的確にせよ
12.4.4 リスクに従って作業を集中させよ
12.4.5 説明的な名前を選択せよ
12.4.6 用語を定義せよ
12.4.7 わかりやすくせよ
12.4.8 定義された表記法を使用せよ
12.4.9 暗黙のセマンティクスに注意せよ
12.4.10 モデルの妥当性を確認せよ
12.4.11 モデルを持続せよ
12.5 アジャイルチームとのモデル化
12.6 チェックリスト
12.7 要約
12.8 参考文献
13 アーキテクチャ記述を作成する
13.1 効果的なアーキテクチャ記述の特性
13.1.1 正確性
13.1.2 十分性
13.1.3 タイムリー性
13.1.4 簡潔性
13.1.5 明瞭性
13.1.6 適用性
13.1.7 精密性
13.2 用語解説
13.3 ISO基準
13.4 アーキテクチャ記述の内容
13.4.1 文書管理
13.4.2 目次
13.4.3 概論と経営陣向け要約
13.4.4 ステークホルダ
13.4.5 一般的なアーキテクチャ原理
13.4.6 アーキテクチャ上の設計判断
13.4.7 ビューポイント
13.4.8 ビュー
13.4.9 品質特性の要約
13.4.10 重要なシナリオ
13.4.11 決定待ちの課題
13.4.12 付録
13.5 アーキテクチャ記述を提示する
13.6 チェックリスト
13.7 要約
13.8 参考文献
14 アーキテクチャを評価する
14.1 なぜ、アーキテクチャを評価するのか？
14.2 評価のテクニック
14.2.1 プレゼンテーション
14.2.2 フォーマルレビューと構造化ウォークスルー
14.2.3 シナリオ使用による評価
14.2.4 プロトタイプと構想実証システム
14.2.5 スケルトンシステム
14.3 シナリオベース評価手法
14.3.1 アーキテクチャを中心としたアクティビティ
14.3.2 スーテクホルダを中心としたアクティビティ
14.4 ソフトウェアライフサイクル中での評価
14.5 既存システムのアーキテクチャの妥当性を確認する
14.6 評価の結果を記録する
14.7 評価アプローチを選択する
14.8 チェックリスト
14.9 要約
14.10 参考文献
第3部 ビューポイントカタログ
15 ビューポイントカタログ概論
16 コンテクストビューポイント
16.1 関心事
16.1.1 システムスコープと責務
16.1.2 外部エンティティの識別と使用されるサービスおよびデータ
16.1.3 外部エンティティの性質と特徴
16.1.4 外部インタフェースの識別と責務
16.1.5 外部インタフェースの性質と特徴
16.1.6 その他の外部依存性
16.1.7 システムが環境に与える影響
16.1.8 全体としての完全性と整合性および統一性
16.1.9 ステークホルダの関心事
16.2 モデル
16.2.1 コンテクストモデル
16.2.2 相互作用のシナリオ
16.3 問題と落とし穴
16.3.1 欠けているまたは正しくない外部エンティティ
16.3.2 見逃している暗黙の依存性
16.3.3 いい加減または不正確なインタフェース記述
16.3.4 不適切な詳細レベル
16.3.5 スコープのずれ
16.3.6 暗黙または当然と考えられているコンテクストやスコープ
16.3.7 入り組み過ぎている相互作用
16.3.8 専門用語の使い過ぎ
16.4 チェックリスト
16.5 参考文献
17 機能的ビューポイント
17.1 関心事
17.1.1 機能的能力
17.1.2 外部インタフェース
17.1.3 内部構造
17.1.4 機能的設計理念
17.1.5 ステークホルダの関心事
17.2 モデル
17.2.1 機能的構造モデル
17.3 問題と落とし穴
17.3.1 定義がお粗末なインタフェース
17.3.2 十分に理解されていない責務
17.3.3 機能要素としてモデル化されたインフラストラクチャ
17.3.4 内容を詰め込み過ぎたビュー
17.3.5 要素定義のない図
17.3.6 複数ステークホルダのニーズの折り合いを付ける難しさ
17.3.7 不適切なレベルの詳細
17.3.8 「神の要素」
17.3.9 過剰な依存性
17.4 チェックリスト
17.5 参考文献
18 情報ビューポイント
18.1 関心事
18.1.1 情報の構造と内容
18.1.2 情報の目的と用途
18.1.3 情報所有権
18.1.4 エンタープライズ所有情報
18.1.5 識別子とマッピング
18.1.6 情報セマンティクスの揮発性
18.1.7 情報ストレージモデル
18.1.8 情報フロー
18.1.9 情報の整合性
18.1.10 情報品質
18.1.11 タイムリー性と持ち時間（レイテンシ）および寿命
18.1.12 アーカイブとデータ保存
18.1.13 ステークホルダの関心事
18.2 モデル
18.2.1 静的情報構造モデル
18.2.2 情報フローモデル
18.2.3 情報ライフサイクルモデル
18.2.4 情報モデルのその他のタイプ
18.3 問題と落とし穴
18.3.1 表現の矛盾
18.3.2 避けられない複数の更新者
18.3.3 キーマッチングの欠陥
18.3.4 インタフェースの複雑さ
18.3.5 過負荷の中央データベース
18.3.6 整合性のない分散データベース
18.3.7 低い情報品質
18.3.8 過剰な情報待ち時間
18.3.9 不適切なボリューム分析
18.4 チェックリスト
18.5 参考文献
19 並行性ビューポイント
19.1 関心事
19.1.1 タスク構造
19.1.2 機能要素のタスクへのマッピング
19.1.3 プロセス間通信
19.1.4 状態管理
19.1.5 同期化と完全性
19.1.6 サポートするスケーラビリティ
19.1.7 スタートアップとシャットダウン
19.1.8 タスク障害
19.1.9 再入可能性
19.1.10 ステークホルダの関心事
19.2 モデル
19.2.1 システムレベルの並行性モデル
19.2.2 状態モデル
19.3 問題と落とし穴
19.3.1 誤った並行性のモデリング
19.3.2 並行性の誤ったモデリング
19.3.3 過剰な複雑さ
19.3.4 リソースの競合
19.3.5 デッドロック
19.3.6 競合状態
19.4 チェックリスト
19.5 参考文献
20 開発ビューポイント
20.1 関心事
20.1.1 モジュール構成
20.1.2 共通処理
20.1.3 設計の標準化
20.1.4 テストの標準化
20.1.5 インストゥルメンテーション
20.1.6 コードライン構成
20.1.7 ステークホルダの関心事
20.2 モデル
20.2.1 モジュール構造モデル
20.2.2 共通設計モデル
20.2.3 コードラインモデル
20.3 問題と落とし穴
20.3.1 詳細過ぎる
20.3.2 過剰なアーキテクチャ記述
20.3.3 一様でない焦点
20.3.4 開発者への注目の欠如
20.3.5 正確性不足
20.3.6 指定した環境に関する問題
20.4 チェックリスト
20.5 参考文献
21 配置ビューポイント
21.1 関心事
21.1.1 必要となる実行時プラットフォーム
21.1.2 必要となるハードウェアまたはホストの仕様と量
21.1.3 サードパーティソフトウェアの要求
21.1.4 テクノロジーの互換性
21.1.5 ネットワーク要求
21.1.6 必要なネットワーク容量
21.1.7 物理的制約
21.1.8 ステークホルダの関心事
21.2 モデル
21.2.1 実行時プラットフォームモデル
21.2.2 ネットワークモデル
21.2.3 テクノロジー依存性モデル
21.2.4 モデル間の関係
21.3 問題と落とし穴
21.3.1 不明瞭または不正確な依存性
21.3.2 実証されていないテクノロジー
21.3.3 適切でないまたは欠けているサービスレベルの同意
21.3.4 専門知識の欠如
21.3.5 配置環境検討の遅れ
21.3.6 サイト間複雑性の無視
21.3.7 不適切なヘッドルーム提供
21.3.8 災害回復環境を指定しないこと
21.4 チェックリスト
21.5 参考文献
22 運用ビューポイント
22.1 関心事
22.1.1 インストールとアップグレード
22.1.2 機能の移行
22.1.3 データの移行
22.1.4 運用の監視と制御
22.1.5 警告
22.1.6 構成管理
22.1.7 パフォーマンス監視
22.1.8 サポート
22.1.9 バックアップとリストア
22.1.10 サードパーティ環境での運用
22.1.11 ステークホルダの関心事
22.2 モデル
22.2.1 インストールモデル
22.2.2 移行モデル
22.2.3 構成管理モデル
22.2.4 管理モデル
22.2.5 サポートモデル
22.3 問題と落とし穴
22.3.1 運用スタッフとの取り決め不足
22.3.2 バックアウト計画の欠如
22.3.3 移行計画の欠如
22.3.4 不十分な移行期間
22.3.5 足りない管理ツール
22.3.6 本番環境の制約
22.3.7 本番環境への統合不足
22.3.8 不十分なバックアップモデル
22.3.9 不適切な警告
22.4 チェックリスト
22.5 参考文献
23 ビュー間の整合性を実現する
23.1 ビュー間の関係
23.2 コンテクストビューと機能的ビューの整合性
23.3 コンテクストビューと情報ビューとの整合性
23.4 コンテクストビューと配置ビューとの整合性
23.5 機能的ビューと情報ビューの整合性
23.6 機能的ビューと並行性ビューの整合性
23.7 機能的ビューと開発ビューの整合性
23.8 機能的ビューと配置ビューの整合性
23.9 機能的ビューと運用ビューの整合性
23.10 情報ビューと並行性ビューの整合性
23.11 情報ビューと開発ビューの整合性
23.12 情報ビューと配置ビューの整合性
23.13 情報ビューと運用ビューの整合性
23.14 並行性ビューと開発ビューの整合性
23.15 並行性ビューと配置ビューの整合性
23.16 配置ビューと運用ビューの整合性
第4部 パースペクティブカタログ
24 パースペクティブカタログ概論
25 セキュリティパースペクティブ
25.1 ビューへの適用可能性
25.2 関心事
25.2.1 リソース
25.2.2 主体
25.2.3 方針
25.2.4 脅威
25.2.5 機密性
25.2.6 完全性
25.2.7 可用性
25.2.8 説明責任
25.2.9 検出と回復
25.2.10 セキュリティメカニズム
25.3 アクティビティ：セキュリティパースペクティブを適用する
25.3.1 機密にかかわるリソースの識別
25.3.2 セキュリティ方針の定義
25.3.3 システムに対する脅威の識別
25.3.4 セキュリティ実装の設計
25.3.5 セキュリティリスクの評価
25.4 アーキテクチャ戦術
25.4.1 広く認められているセキュリティ原理の適用
25.4.2 主体の認証
25.4.3 アクセスの許可
25.4.4 情報守秘の保証
25.4.5 情報完全性の保証
25.4.6 説明責任の保証
25.4.7 可用性の保護
25.4.8 セキュリティテクノロジーの統合
25.4.9 セキュリティ管理の提供
25.4.10 サードパーティのセキュリティインフラストラクチャ利用
25.5 問題と落とし穴
25.5.1 複雑なセキュリティ方針
25.5.2 実証されていないセキュリティテクノロジー
25.5.3 障害対応の設計がなされていないシステム
25.5.4 管理機能の欠如
25.5.5 テクノロジー駆動アプローチ
25.5.6 時間ソースの検討不足
25.5.7 テクノロジーへの過剰保存
25.5.8 明確な要求やモデルの欠如
25.5.9 後知恵のセキュリティ
25.5.10 インサイダ脅威の無視
25.5.11 クライアントは安全という思い込み
25.5.12 アプリケーションコードに埋め込まれたセキュリティ
25.5.13 切れ切れのセキュリティ
25.5.14 その場しのぎのセキュリティテクノロジー
25.6 チェックリスト
25.6.1 要求把握のためのチェックリスト
25.6.2 アーキテクチャ定義のためのチェックリスト
25.7 参考文献
26 パフォーマンスとスケーラビリティパースペクティブ
26.1 ビューの適用可能性
26.2 関心事
26.2.1 応答時間
26.2.2 スループット
26.2.3 スケーラビリティ
26.2.4 予測可能性
26.2.5 ハードウェアリソース要求
26.2.6 ピーク負荷時の振る舞い
26.3 アクティビティ：パフォーマンスとスケーラビリティパースペクティブを適用する
26.3.1 パフォーマンス要求の把握
26.3.2 パフォーマンスモデルの作成
26.3.3 パフォーマンスモデルの分析
26.3.4 実用的テストの実施
26.3.5 要求に対しての評価
26.3.6 アーキテクチャの再作成
26.4 アーキテクチャの戦術
26.4.1 反復処理の最適化
26.4.2 複製による競合抑制
26.4.3 処理の優先順位づけ
26.4.4 関連する作業負荷の統合
26.4.5 処理の時間的分散
26.4.6 共有リソース使用の最小化
26.4.7 リソースと結果の再利用
26.4.8 区分と並列化
26.4.9 スケールアップまたはスケールアウト
26.4.10 上品な格下げ
26.4.11 非同期処理の使用
26.4.12 トランザクションの整合性緩和
26.4.13 設計の妥協
26.5 問題と落とし穴
26.5.1 的確でないパフォーマンスおよびスケーラビリティの目標
26.5.2 非現実的なモデル
26.5.3 複雑な場合への単純な手段の使用
26.5.4 不適切な区分
26.5.5 根拠のない環境とプラットフォームの前提
26.5.6 過剰な関節処置
26.5.7 並行性関連の競合
26.5.8 データベースの競合
26.5.9 トランザクションのオーバーヘッド
26.5.10 不注意なリソースの割り当て
26.5.11 ネットワーク起動とプロセス内起動の相違無視
26.6 チェックリスト
26.6.1 要求把握のためのチェックリスト
26.6.2 アーキテクチャ定義のためのチェックリスト
26.7 参考文献
27 可用性とレジリエンスパースペクティブ
27.1 ビューの適用可能性
27.2 関心事
27.2.1 サービスのクラス
27.2.2 計画停止時間
27.2.3 計画外の停止時間
27.2.4 修理の時間
27.2.5 災害回復
27.3 アクティビティ：可用性とレジリエンスパースペクティブを適用する
27.3.1 可用性要求の把握
27.3.2 可用性スケジュールの作成
27.3.3 プラットフォーム可用性の見積り
27.3.4 機能的可用性の見積り
27.3.5 要求に対しての評価
27.3.6 戦術を適用したアーキテクチャ再作成
27.4 アーキテクチャ戦術
27.4.1 フォールトトレラントハードウェアの選択
27.4.2 高可用性クラスタ化とロードバランシングの使用
27.4.3 トランザクションの記録
27.4.4 ソフトウェア可用性解決策の適用
27.4.5 フォールトトレラントソフトウェアの選択または作成
27.4.6 障害に備えた設計
27.4.7 コンポーネント複製の許容
27.4.8 トランザクションの整合性緩和
27.4.9 バックアップと災害回復の解決策識別
27.5 問題と落とし穴
27.5.1 単一の故障個所
27.5.2 カスケード障害
27.5.3 過負荷による使用不可
27.5.4 野心的過ぎる可用性要求
27.5.5 効果のないエラー検出
27.5.6 コンポーネントレジリエンスの最大見積り
27.5.7 見過ごされれるグローバルな可用性要求
27.5.8 互換性のないテクノロジー
27.6 チェックリスト
27.6.1 要求把握のためのチェックリスト
27.6.2 アーキテクチャ定義のためのチェックリスト
27.7 参考文献
28 発展性パースペクティブ
28.1 ビューの適用可能性
28.2 関心事
28.2.1 製品管理
28.2.2 変更の規模
28.2.3 変更の次元
28.2.4 変更の可能性
28.2.5 変更の時間的尺度
28.2.6 変更の対価を払う時期
28.2.7 外部要因がもたらす変更
28.2.8 開発の複雑さ
28.2.9 知識の保存
28.2.10 変更の信頼性
28.3 アクティビティ：発展性パースペクティブを適用する
28.3.1 発展性ニーズの特徴づけ
28.3.2 現在の発展性容易度評価
28.3.3 発展性トレードオフの検討
28.3.4 アーキテクチャの再作成
28.4 アーキテクチャ戦術
28.4.1 変更の阻止
28.4.2 拡張可能なインタフェースの作成
28.4.3 変更を容易にする設計テクニックの適用
28.4.4 メタモデルベースのアーキテクチャスタイル適用
28.4.5 ソフトウェアへのバリエーションポイントの組み込み
28.4.6 標準の拡張ポイントの使用
28.4.7 信頼できる変更の実現
28.4.8 開発環境の保存
28.5 問題と落とし穴
28.5.1 誤った次元の優先順位づけ
28.5.2 決して起こらない変更
28.5.3 重要な品質特性に対する発展性の影響
28.5.4 特定のハードウェアやソフトウェアに対する過大な依存
28.5.5 失われた開発環境
28.5.6 その場そのぎのリソース管理
28.6 チェックリスト
28.6.1 要求把握のためのチェックリスト
28.6.2 アーキテクチャ定義のためのチェックリスト
28.7 参考文献
29 その他のパースペクティブ
29.1 アクセシビリティパースペクティブ
29.1.1 ビューの適用可能性
29.1.2 関心事
29.1.3 アクティビティ：アクセシビリティパースペクティブを適用する
29.1.4 アーキテクチャ戦術
29.1.5 問題と落とし穴
29.1.6 チェックリスト
29.1.7 参考文献
29.2 開発リソースパースペクティブ
29.2.1 ビューの適用可能性
29.2.2 関心事
29.2.3 アクティビティ：開発リソースパースペクティブを適用する
29.2.4 アーキテクチャ戦術
29.2.5 問題と落とし穴
29.2.6 チェックリスト
29.2.7 参考文献
29.3 国際化パースペクティブ
29.3.1 ビューの適用可能性
29.3.2 関心事
29.3.3 アクティビティ：国際化パースペクティブを適用する
29.3.4 アーキテクチャ戦術
29.3.5 問題と落とし穴
29.3.6 チェックリスト
29.3.7 参考文献
29.4 配置場所パースペクティブ
29.4.1 ビューの適用可能性
29.4.2 関心事
29.4.3 アクティビティ：配置場所パースペクティブを適用する
29.4.4 アーキテクチャ戦術
29.4.5 問題と落とし穴
29.4.6 チェックリスト
29.4.7 参考文献
29.5 規則パースペクティブ
29.5.1 ビューの適用可能性
29.5.2 関心事
29.5.3 アクティビティ：規則パースペクティブを適用する
29.5.4 アーキテクチャ戦術
29.5.5 問題と落とし穴
29.5.6 チェックリスト
29.5.7 参考文献
29.6 使用性パースペクティブ
29.6.1 ビューの適用可能性
29.6.2 関心事
29.6.3 アクティビティ：使用性パースペクティブを適用する
29.6.4 アーキテクチャ戦術
29.6.5 問題と落とし穴
29.6.6 チェックリスト
29.6.7 参考文献
第5部 すべてを1つにまとめる
30 ソフトウェアアーキテクトとして仕事をする
30.1 プロジェクトライフサイクルにおけるアーキテクチャ
30.1.1 小規模で低リスクのプロジェクトにおけるアーキテクチャ
30.1.2 アジャイルプロジェクトにおけるアーキテクチャ
30.1.3 計画駆動プロジェクトにおけるアーキテクチャ
30.1.4 大型プロジェクトにおけるアーキテクチャ
30.2 いろいろなタイプのプロジェクトをサポートする
30.2.1 社内システム開発
30.2.2 新製品開発
30.2.3 エンタープライズサービス
30.2.4 既存のシステムの拡張
30.2.5 パッケージ実装
30.2.6 インターネット対応
30.2.7 使用廃止
付録 その他のビューポイントセット
A.1 KRUCHTENの「4+1」
A.2 RM-ODP
A.3 シーメンス（HOFMEISTER、NORD、SONI）
A.4 SEI “Views and Beyond"ビュー
A.5 GARLANDとANTHONY
A.6 IAF
A.7 エンタープライズアーキテクチャフレームワーク
A.7.1 Zachmanフレームワーク
A.7.2 TOGAF
A.8 その他のエンタープライズアーキテクチャフレームワーク
参考文献
索引
第2版訳者あとがき