ソフトウェアアーキテクチャ その3 - 表現方法のコンセプト [arch]
今回はソフトウェアアーキテクチャの「表現方法」について．
Reference:
Documenting Software Architectures: Views and Beyond,
by Clements, et al. Addison-Wesley 2003
--> Part I
本書には，Appendix に ECS Software のアーキテクチャ仕様書がそのまま例として載っており，私もアーキテクチャ仕様書を記述する際に大いに参考にしている．
但し，本書には関わっている著者が多く，全体的に若干繁雑な内容になっていることは否めない．最初から最後まで読了するというよりは，必要に応じて適切な内容を参照するカタログ代わりに利用すると良いかもしれない．
こちらがその和訳本．
多くの技術書がそうであるように，この和訳書も日本語が非常に奇怪だ．特に本書はその傾向が顕著で，例えば linked list (リンクリスト) が「結合した一覧表」などと訳されている．特に本書に関しては，極力オリジナルを読まれることを強くお勧めする．
ソフトウェアを表現する時に覚えておきたいのが，"View" "Viewtype" "Pattern" という概念だ．簡単に言ってしまうと，
- View は絵
- Viewtype はある視点からの絵
- Pattern は見慣れた絵
ということになる．
以下，詳細に説明してみよう．
前回 解説した定義によると，ソフトウェアアーキテクチャ は "structure(s)" ということだったが，"view" とはこの structure の描写である．無形で複雑なソフトウェアを捉えるには，様々な角度から表現される必要があり，この1つ1つが view である．一般的にアーキテクチャドキュメントは， view の集合 (とその相互作用の説明) で構成される．
例えば外科医，内科医，整形外科医は全て人体の構造 (structure) について異なる見方を持っているし，一部の組織に注目する眼科医もいれば，振る舞いについて観察する精神科医もいる．実体 (structure) における必要な個所を，様々な視点から可視化させるという点においては，ソフトウェアでも同じことである．
同じような例えを，本書は鳥の翼を用いて行っている．羽，骨格，血液，筋肉といった様々な view について，
これらの view のどれが翼の「アーキテクチャ」か．
いずれでもない．
これらの view のどれから翼の「アーキテクチャ」が持たらされるのか．
全てからである．
(ちなみにこのコンセプトから本書の表紙が鳥の翼になっている)
Viewtype とはシステムを捉える視点であり，具体的には "Module viewtype (静的観点)" "Component and Connector viewtype (動的観点)" "Allocation viewtype (物理的観点)" という3つに大きく分類される．基本的に view はこのどれかの viewtype にカテゴライズされる．
Module viewtype は，クラス，関数，インターフェースなどを扱い，責務を実装するコードの単位を示す．表現する関係は，is-part-of，depends-on，is-a のいずれかである．コードの青写真として使われ，モジュールは実装チームに割り当てられる．プロジェクトマネージメントや計画，プランニングを検討する際にも有効だ．
C&C viewtype は，プロセス，シーケンス，データフローなどを扱い，システムの動的な振る舞いを示す．通信メカニズムや，可用性，パフォーマンス，セキュリティ，信頼性などの分析に有効だ．
Allocation viewtype は，デバイス，ネットワーク，人員などを扱い，ソフトウェアが非ソフトウェアにどう割り当てられるかを示す．具体的に「非ソフトウェア」とは，主にハードウェアの場合が多いが，人やコスト，ソースコードのディレクトリツリーなども対象になる．
パフォーマンス性を可視化させたいなら C&C view，再利用性を可視化させたいなら Module view といった具合に，アーキテクトは適切な view を切り出して，ステークホルダーが興味を持つ structure を表現しなければならない．2つの view が混在していたり，視点が曖昧なままのドキュメントを多く見かけるが，これでは的確にソフトウェアを表現できないだろう．
また，「アーキテクチャドキュメント」というとレイヤ構造図や依存関係図ばかり見る気がするが，むしろソフトウェアアーキテクチャを本質的に表現するのは動的分析図だと個人的には思っている．
Pattern (style と呼ばれることもある) とは，要素と関係のタイプの使用法に対し，一連の制約をつけ，要素と関係のタイプを特殊化したものである．分かりやすく言うと，それぞれの viewtype でシステムをまたいで頻繁に登場するような表現を抽出し，一般化したものが pattern である (「デザインパターン」もこの1種と言える)．
それぞれの viewtype における pattern の例を挙げておくと，
Module viewtype:
- Decomposition (分割)
- Uses (依存関係)
- Layered (レイヤ)
- Class, generalization (クラス，汎化)
など．
C&C viewtype:
- Data Flow (Pipe-filter など)
- Call-and-return (Client-server など)
- Interacting processes (Event system など)
- Data-oriented repository (Blackboard など)
- Hierarchical (Tiers など)
など．
Allocation viewtype:
- Deployment (配置)
- Implementation (ファイルシステム)
- Work Assignment (作業割り当て)
など．
ところで "view" の概念には他にも様々なコンセプトがある．Philippe Kruchten が1995年に提唱した 4+1 (Four Plus One) view model の考え方はあまりにも有名で，今日では RUP (Rational Unified Process) の概念的な基礎として定着している．
- Logical (論理) view
- Process (プロセス) view
- Development (配置) view
- Physical (物理) view
(+1 の Use case view は，上記4つの全てにまたがる)
http://www-128.ibm.com/developerworks/wireless/library/wi-arch11/
この 4+1 view model と，本書の上記 view との対応は，第11章で解説されている．他にも11章には，UML や Siemens Four View などといった概念と本書の概念の対応が解説されているので，興味のある方は目を通すと良いかもしれない．
最後にもう1度，ソフトウェアを表現したものを見る時，見せる時は，「どの視点からソフトウェアを捉え，どの view を切り出しているか」を明確にすることが非常に重要であることを，繰り返し強調しておきたい．
0 コメント:
コメントを投稿