ソフトウェアアーキテクチャの文書化についての本。
その具体的な方法が記述されている。
テンプレもあるので、それを活用していきたい。
序章
7つのルールを守らねばならない。
- 読み手の視点で書く
- 不必要な繰り返しはしない。混乱の元
- 曖昧さを避ける。独自のUML的なものを書いてもよいが処理なのかデータの流れ7日曖昧なものは避ける
- 標準的な構成を採用する
- 根拠を記載する
- できるだけ最新を保つ
- 目的に合致しているかレビューする
1部序文
ここにビューの種類がいくつかとそれを記述するときのテンプレートが記述されている。
迷ったらここに戻って見直すのはありだと思う
1章
モジュールビュータイプ
他のビューのもととなることが多い。
C&Cビューに利用されたり、組織分割と紐付いたりする。
サブシステムごとの依存関係やなにの一部であるのかなどを記述する。
2章
モジュールビュータイプのスタイルについて。
3つのスタイルについて記述している。
・分解スタイル
大体の人が分解スタイルから始める。
一部を外部調達するのか。プロダクトラインをどうこうせいするのか？プロダクトラインを作るのであるならばだが。
分解の目的は、管理可能な粒度まで分割して管理するためである。
そのため、分解は繰り返し行われる。
C&Cビューと紐付けを行うことが望ましい。
・使用スタイル
どのモジュールがどのモジュールを使用しているのか。依存しているのかを明らかにする。
依存関係が明らかならば、どこでMockを作ればよいかとか計画などが立てやすくなる。
また、テストのときの影響についても検証可能になる。
・汎化スタイル
かなり実装に近づいている。
とはいえ、汎化した上で具体的な実装がチームごとに分かれるくらいに巨大なシステムであれば有効である。
汎化によるサブシステムの差し替えとか。
・レイヤースタイル
レイヤーは縦に並べることもあれば、円になることもある。
レイヤードアーキテクチャーやヘキサゴナルアーキテクチャなどである。
移植可能性や再利用性について記述する際に必要になる。
ライブラリーなどでは必須だと思われる。
3章
コンポーネント-コネクタービュータイプ
正直、この章だけ読んでもC&Cについては、あまり良くはわからない。
重要なのは、C&Cの表現を利用することで、データの記憶、複製、通信プロトコル、並行性、変更可能性。これらを明らかにすることだ。
プロセスや通信方法やデータの保存を表現するので、実装に近づいた感じはする。
また、モジュールビューはコードなどに依存するのに対して、C&Cはプロセスや処理に依存するので、Configなどは表現されない気がする。
ただ、データが入るのでなんとも言えない。
4章
・パイプ-フィルタースタイル
重い処理などをフィルターするような信号処理などに利用される。
・共有データスタイル
データの提供元を外部から隠蔽する際に利用する。
GatewayがRepositoryにアクセスするなどのパターンがある。
その際にRPCなのかSQLを実行するのかなどを明確にする必要がある。
・Pub/Sub
Sub側がどの変更されても問題ないように作れるのが利点。
一方で、適切な表現がUMLにない気もする。
・クライアント-サーバー
クライアントが利用するサービスを切り離すことが目的となり、同時接続数などの制限が追加されたりする。
・通信プロセススタイル
並行して動作できるシステムや、コンポーネントのどれを束べて実行単位とするのかを記述する。
UMLでC&Cを表現するにあたっては、凡例が重要となる。
決まった書き方がないので、きちんと定義しないと後々の混乱が大きくなる。
コンポーネントは、モジュールビューの場合はコードと対応するが、C&Cの場合はプロセスなどと対応する。同じものが別の側面を持つ。
5章
割り付けタイプは、３つのスタイルがある。
・配置スタイル
物理的にどこにあるのか。どこで保存されるのか実行されるのかの観点で書く。
性能やセキュリティの観点で書くことになる。
・実装スタイル
ファイルのディレクトリの構成などを記述することになる。
システムのバージョンごとに作られる
・作業割当スタイル
買ってくる製品であっても担当者は置くべき。
表でセグメント、サブシステム、担当部門のような形で書けばよい。
６章
Top level context diagramを書くのはプロジェクト全体を俯瞰するのには良い。
作成するシステムとそれ以外のように分けて、相互にやり取りする情報を記述する
結合ビューは、複数のビューの関係性を記述する。
たとえば、モジュールビューとプロセスビューのような形。
7章
Interface設計書の構成
１．インターフェースの独自性。名前をつけバージョンをつける
２．提供されるリソースを明らかにする
２−１．引数とデータタイプ
２−２．リソースの意味。データの取りうる値。サイドエフェクト。外部から見た変化
２−３．制限。リソースにアクセス可能な数など
３．データタイプ。
４．エラー処理。エラー条件。
５．可変性
６．インターフェースの品質特性
７．要素の要求。呼び出しの前提条件など
８．設計の根拠と設計上の課題。背景や妥協した点など
９．ユーザーガイド。
8章
振る舞いの表し方。
・トレース。文章による書き下し。どのような刺激の結果として、どのような応答があるのかを記述する。
・ユースケースマップ。システムのin/outを記述する。また、リソースがどの処理で消費されるかを記述する。複数のケースを同時に記述可能なので、デットロックなどを見つけやすい
・シーケンス図。シーケンスは、時間に注目したものとなる。平行性などは記述しにくい。また、時間に注目するので一つのシナリオしか記述するのが難しい。
・コラボレーションズ。要素間の相互作用について記述する。シーケンスと同じようなことが書かれるが、要素間の関係性が俯瞰で見られる。
・メッセージシーケンス。あまり使わなさそう。
・静的モデル。ステートチャートは状態を表し、入れ子構造を持つ。システムが取りうるすべての状態を網羅的に記述できる。
ユースケースマップは、実験的なものだがサンプルなどはある。
振る舞いを表すサンプルなどは比較的世の中に豊富にある。
9章
アーキテクチャ文書は、すべてのViewについて書いていたらきりがない。
各ステークホルダとそれらの人の関心事の星取表を作る必要がある。
その上で、同じにできるものはあるかを検証し、数を減らす。そのうえで優先順位をつけていく。
10章
設計書のパッケージの作成について。
各Viewについては、こういったテンプレートがあるので利用すべき
文書全体については以下のような構成になる。
これが全体で、各ビューについてを２のところに書いていけば良いと思う。
設計書のレビューが必要だが、最初にプロセスについて説明したあとで、小さいグループでレビューを勧めたほうが意見が出やすい。また、設計者がレビューアに積極的に質問することで有意義なレビューにできる。
また、設計書とは別にプレゼン資料も作るべき。
1時間で50枚程度で以下のような構成
11章
UMLなどについて、どのようが表現方法があるのかが示されている。
