BSA / Creating Architectural Understanding

Creating Architectural Understanding †

要約 †

以前に示したアーキテクチャの定義をふりかえる

• 開発チームにとっての重要な基準は、ソースコードに頼ることなくアーキテクチャの理解を明らかにし、 記述し、会話し、そして修正するのに、いくつかのやり方があること
• 1つ以上のモデルは、チームが全体像のレベルで取り扱うのに絶対に必要
  • これをするにはいろいろなモデルがあり、そのいくらかでうまくいったものもある
    • 最近はRational 4+1モデルを使っている

主にソフトウェアプロセスの主要となる関係者の要求を満たすことに基いて、 Ratinal 4+1モデルはアーキテクチャの4つの観点を薦めている

• Logical view
  • システムの開発でオブジェクトやエンティティ間の関係の静的なスナップショット
  • 2つ以上の表現がある
    • ひとつは概念モデル
    • もうひとつはデータベーススキーマモデル
• Process view
  • 設計の並行性と同期性を表現したもの
• Physical view
  • ハードウェア上にソフトウェアをマッピングしたもの
  • 高可用性、信頼性、耐障害性、パフォーマンスを目的としたコンポーネントの分配も含む
• Development view
  • 開発環境におけるソフトウェアの静的な構成を表現したもの

ソフトウェアの設計者は4つのビューの周りでアーキテクチャ上の決断を体系化できる

• システムの理解を容易にするのに、それぞれのビューは主なユースケースのコンテキストで記述される
  • 全てのユースケースは+1のアーキテクチャビューを構成する

4つのビューに制限していないので、本来はn+1として参照されるべき

• ソフトウェアアーキテクチャを表現する上での主な決まり事は、正しいアーキテクチャモデリングの複数のビューが必要なのをはっきりと理解すること
• 誰も独断的に3つか5つ使うよう要求することはできない
  • けれども、提供されたビューのコミュニケーション特性の理解と、必要に応じてこのビューを使うことを促せる

複雑なシステムの複数のモデルのコンセプトがとてもありふれたものなのは驚くべきことではない

• 筆者は建てた家と改修した家を持っていて、建築家によってプロデュースされた家の多くのモデルを注意深く読むのを学んでいるところ
  • 配置図から配電図から照明図から正面図から配管図に至るまで
• 専門的でスキルのある作業者は家を作るのにこれらのモデルすべてを必要とし、可能な限り気に入る家を設計することをよく確かめる

ラショナルやその他で普及されるアーキテクチャの様々な観点といったプランの価値は、 比較的長い間価値のある成果物をチームに提供すること

• 更に一般論として、アーキテクチャのパーツの表現は、比較的長く続く問題、問題のドメイン、ビジネスモデル（4章）、 そしてこれらの間に存在する技術的な解決策の特別な観点を扱う時間、労力、お金の価値に値する