アーキテクチャーは、技術やメンバーだけでなく様々なものに影響を受ける。
アーキテクチャーは少人数で作成さ、文書化されなければならない。
この章に書いてあることが全体のチェックリストになる気もするので、あとで書き下す。
２章
アーキテクチャーは利害関係者のコミュニケーション手段
初期の設計方針を決める。品質特性を決める。組織構造を決定する。再利用可能なものを抜き出すことができる。
どのようなコード単位で構造化するのか？(モジュール)
実行時の振る舞いの単位(コンポーネント)とその相互作用(コネクター)
それらをどの環境に置くか(割当)
の大きく分けて3つのビュー(見方)がある。
更に、細部には様々な要素があるがすべてをドキュメント化する必要はない。
論理ビュー
オブジェクトやクラスなどの(モジュールビュー)
プロセスビュー
並行性と機能の分散を扱い
配置ビュー
ライブラリや開発の単位
物理ビュー
プロセスや通信のノードへのマッピングを示す
How(どのように)よりはWhat(何を)するのかを明らかにすることで、議論ができるようになる。
３章
A7-E航空電子工学プロジェクトを具体例としてアーキテクチャーの構造について説明している。
分割構造は、どのようにモジュールに分割するのか？
ハードウェアを隠蔽するモジュール
ビジネスロジックを分割していくモジュール
アルゴリズムなどを格納するモジュール
使用の構造は、どの処理がどの処理を参照するのか？などだ。Layer化アーキテクチャだと改装をまたいだ参照はしないなど。
プロセス構造は
同期の順番や排他制御の場所など
航空機の具体的なものはそんなに語られていない。
第２部
アーキテクチャーと品質について。
品質はむる人によって変わる。
４章
アーキテクチャのなかで特に重要な品質特性について。
また、品質特性をどのように表現するのか。
品質特性は
刺激の発生源、刺激、環境、成果物、応答、応答測定
から表現される。
可用性を具体例とすると
可用性のシナリオ
- 刺激の発生源
- システムの内部/外部
- 刺激
- クラッシュ、障害
- 成果物
- システムの処理、メモリー、プロセッサ
- 環境
- 通教稼働している状況か、異常な状況か。
- 応答
- 記録をとる、通知をする
- 応答測定
- システムが使用可能な時間の計測、縮退状態の時間計測
変更性のシナリオ
- 刺激の発生源
- ユーザー、開発者、システム管理者
- 刺激
- 機能、品質特性に対する追加改善変更
- 成果物
- システム、UI、プラットフォーム
- 環境
- 実行時、コンパイル時、設計時の環境
- 応答
- テストし、配置する
- 応答測定
- 時間、コスト
性能のシナリオ
- 刺激の発生源
- ユーザー
- 刺激
- トランザクション、秒間X回、read, write
- 成果物
- システム
- 環境
- 通教状態/非常状態/高負荷状態
- 応答
- トランザクションが処理された結果
- 応答測定
- イベントが発生してからの応答の時間
セキュリティのシナリオ
- 刺激の発生源
- 個人/システム、権限のある/ない、
- 刺激
- データの変更の試み
- 成果物
- システム内のデータ
- 環境
- オンライン/オフライン、ファイアウォール内/外
- 応答
- アクセスを承認する/拒絶する/記録する
- 応答測定
- アクセスの記録/攻撃の検出/データの復元
- 刺激の発生源
- テスト担当者
- 刺激
- テストの実行
- 成果物
- 設計、コード
- 環境
- 設計時、コンパイル時、Deply時
- 応答
- テスト結果
- 応答測定
- カバー率、実施時間、依存関係
使いやすさのシナリオ
- 刺激の発生源
- ユーザー
- 刺激
- ユーザーニーズ、効率的に使いたい、エラーを最小化したいなど
- 成果物
- システム
- 環境
- 実行時、設定時
- 応答
- システム学習支援/効率的な利用支援/エラーの最小化/国際化
- 応答測定
- 作業時間、エラー数など
様々な品質特性はトレードオフの関係にある。これを比較するために刺激に着目し、関連するのか独立しているのかをまとめると良い。
他にも規模拡張性、移植性などの品質特性がある。
ビジネス品質
- 市場投入までの時間
- コストと利益
- システムの寿命予測
- targeted market
- 改善投入スケジュール
- 既存システムとの統合
５章
アーキテクチャーの実現方法がテーマではあるが、やや抽象的な話に終止する。
可用性
多数決というのは、複数システムにより処理して、多数のシステムがOKならOKとかそういうこと。
変更容易性
セキュリティ
使いやすさ
性能
テスト容易性
６章
航空管制システムを例にとって説明している。
物理ビューや分割ビューなどあって実用的かも。
実現方法をすべて細かくはかけないが、これらをチェック・ポイントして見直せば良いと思う。
物理ビュー
モジュール分割ビュー
プロセスビュー
クライアント・サーバービュー
コードビュー(機能がコードのどこにmappingしているかを示す)
対障害性ビュー
各ビューはシステムの異なる視点からの記述であるため、当然同じような名刺が登場する。
アプリケーションはプロセスやクライアントサーバービューに出てくるといった具合だ。
マッピングを示すことでわかりやすくなる。
ただ、これらは完璧なセットではない。システムによって必要なビューは異なる。
そのシステムがどのような品質特性を満たそうとしているのかを記述するためにこれらはセク製される。
７章
アーキテクチャーを具体的にどのように設計していくのかのステップが記述されている。
そのまま全文のせたいくらいである。
- 分割するモジュールを選択する
- モジュールを詳細化する
- アーキテクチャドライバを選択する
- アーキテクチャパターンの選択
- 複数のビューを用いながらモジュールをインスタンス化して、機能性を割り当てる
- サブモジュールのインターフェースを定義する
- ユースケースと品質シナリオをサブモジュールの制約として検証して、詳細化する
アーキテクチャドライバとはシステムの方向を決める要求のこと
８章
シュミレータについての具体例を示している。
統合容易性という大規模システムでは非常に重要なものを取り扱う。
リアルタイム処理と逐次処理の２つの統合について語られているが、具体的には以下のところくらいだ。
Timeline Synchronizerなるものが統合のメインになりそう。
9章
アーキテクチャーの文書化とは、各ステークホルダーのコミュニケーションの促進であり、システムへの理解を助けることにある。
見るステークホルダーのコミュニケーションのニーズがどこに有るのか？によって視点が変わり、書くべきことも変わる。
9章
アーキテクチャーの文書化とは、各ステークホルダーのコミュニケーションの促進であり、システムへの理解を助けることにある。
見るステークホルダーのコミュニケーションのニーズがどこに有るのか？によって視点が変わり、書くべきことも変わる。
具体的な文書化の方法が書かれており、全体的にリスト化したいところだ。
適切なビューを選択すべきである。
第3部
アーキテクチャーを評価するのは計画的に行われるべきで、それが早期に行われることでシステムの問題が浮き彫りになる。
ATAM、CBAMなどの具体的手法もある。
11章
ATAMの説明と具体例について記述している。
ATAMについては、かなり具体的にきじゅつされている。
評価チーム、アーキテクト、ステークホルダーの3つの集団が評価に参加して、最終的にレポートを上げる。
評価方法のステップまで示されているので、この本に書いてあることをそのまま行えば、きちんと評価できる気はする。ただ、細かすぎるので中くらいのシステムやアーリータイミングでのシステムでは向かないかもしれない。
ただ、規模感を小さくして行うのは価値があると思う
12章
CBAMの具体的な進め方についての記述がある。
コストを考えてて、そこからアーキテクチャーを評価することになるという切り口。
品質特性とコストを場合分けして、それについて投票して決めていくというのは有効な手段であると思う。
ただ、利益を計算して費用対効果が最も良いものを選ぶとあるが、利益がかんたんに計算できることは稀だし、資料作成者の作為が入る可能性が高いと思うので、利益については考慮しないほうが良いのではないかと個人的には思う。
13章
WWWの発展を通して、アーキテクチャーの変更容易性について記述している。
具体的すぎて、逆にWWWの紹介のようになっている。
また、ちょっと規模感が大きすぎて参考にならない面もあるとおもう。
14章以降
プロダクトラインに対する考えと具体例が続く。
プロダクトラインの考え方は、市場に投入する製品群にたいして適切な共通システムを抜き出して再利用するのか？という点にある。
少々ハードウェア寄りで、現在のシステム開発とは違う気もするが視点として共通部分を抜き出すというのは考えるべきところだと思う。
全体を通して言えるのは、組込みシステムなどに向けたアーキテクチャーの例が多いという点だ。
CPUや物理の構成を理解するのは重要だが、現在はそれらも抽象化されており、ある程度雑な見積もりをしてもあとから変えられる部分が大きいので、低レイヤーの設計において、この本の書いてあることを忠実に守る必要はないと思う。
ただ、手法や考え方は現代にも通じると思うし作業リストを作る際の抜け漏れなどをチェックするにも非常に有効な本だと思う。
適切なビューを選択すべきである。
- 候補となるビューをリスト化する
- ビューを組み合わせて文章を見る人のニーズを満たせるかチェックする
- 優先順位をつける
各ビューでは、
- プライマリープレゼンテーション
- 要素カタログ
- コンテキスト図
- 可変性ガイド。どのように変更できるか
- アーキテクチャーの背景
- 用語集
- その他の作者や変更履歴など
を記述する。
また、インターフェースを定義しなければいけない。
どこのインターフェースということだが、システムのインターフェースになると思う。
リソースに着目し、どのリソースをコントロールするモジュールで、どのリソースを提供したり利用したりするモジュールなのかなど。
- インターフェースの識別子(名前やID)
- 提供するリソース
- データ型
- 例外の定義
- 提供されるか編成(関数を受けれて処理を変えられるのかなど)
- 品質特性の特徴
- 要素の要求
- 根拠と設計の背景
- 使用ガイド
また、ビュー間をまたぐ文書を作成する必要もある。
ビュー同士の関係を記述することでわかりやすくなる。
- ビューカタログやビューテンプレートを利用し
- システムの概要とビュー間の要素のマッピングを記述し
- なぜそれが選ばれたのかを記述していく
モデリングにはUMLなどを用いても良い。
10章
アーキテクチャーを再現する。
文書がないときに作ることに相当する。
データから分け始めて、ツールに夜よるのが良さそう。
アーキテクチャーを評価するのは計画的に行われるべきで、それが早期に行われることでシステムの問題が浮き彫りになる。
ATAM、CBAMなどの具体的手法もある。
11章
ATAMの説明と具体例について記述している。
ATAMについては、かなり具体的にきじゅつされている。
評価チーム、アーキテクト、ステークホルダーの3つの集団が評価に参加して、最終的にレポートを上げる。
評価方法のステップまで示されているので、この本に書いてあることをそのまま行えば、きちんと評価できる気はする。ただ、細かすぎるので中くらいのシステムやアーリータイミングでのシステムでは向かないかもしれない。
ただ、規模感を小さくして行うのは価値があると思う
12章
CBAMの具体的な進め方についての記述がある。
コストを考えてて、そこからアーキテクチャーを評価することになるという切り口。
品質特性とコストを場合分けして、それについて投票して決めていくというのは有効な手段であると思う。
ただ、利益を計算して費用対効果が最も良いものを選ぶとあるが、利益がかんたんに計算できることは稀だし、資料作成者の作為が入る可能性が高いと思うので、利益については考慮しないほうが良いのではないかと個人的には思う。
13章
WWWの発展を通して、アーキテクチャーの変更容易性について記述している。
具体的すぎて、逆にWWWの紹介のようになっている。
また、ちょっと規模感が大きすぎて参考にならない面もあるとおもう。
14章以降
プロダクトラインに対する考えと具体例が続く。
プロダクトラインの考え方は、市場に投入する製品群にたいして適切な共通システムを抜き出して再利用するのか？という点にある。
少々ハードウェア寄りで、現在のシステム開発とは違う気もするが視点として共通部分を抜き出すというのは考えるべきところだと思う。
全体を通して言えるのは、組込みシステムなどに向けたアーキテクチャーの例が多いという点だ。
CPUや物理の構成を理解するのは重要だが、現在はそれらも抽象化されており、ある程度雑な見積もりをしてもあとから変えられる部分が大きいので、低レイヤーの設計において、この本の書いてあることを忠実に守る必要はないと思う。
ただ、手法や考え方は現代にも通じると思うし作業リストを作る際の抜け漏れなどをチェックするにも非常に有効な本だと思う。
