今回のコラムはBTABokのコンピテンシーモデルの「Views and Viewpoints」について取り上げます。「コンピテンシー」とは高いパフォーマンスを発揮する人物に共通して見られる「行動特性」を表す言葉で、BTABokのコンピテンシーモデルはその行動特性をモデル化したものになります。ITアーキテクトには幅広い知識とそれを実践する行動力が求められます。そのアーキテクトの「行動特性」を学ぶことでITアーキテクトに必要な知識や行動を理解することができるでしょう。ここではコンピテンシーモデルの中の「Views and Viewpoints」についてみていきます。
基本的にソフトウェアはその構造を物理的に視認することができません。このため構造をステークホルダーに説明するために可視化する必要があり、その可視化によってステークホルダーにソフトウェアがどのような構造をとっているかを理解してもらうためにもわかりやすい可視化のアプローチが求められます。「Views and Viewpoints」は、直訳すると「見解と視点」ですがviewsとviewpointsの原則は異なる場所で若干異なる方法で定義されます。IASA によって採用された定義は次のとおりです。
viewsは、アーキテクチャの 1 つ以上の側面を表現したもので、 1 つ以上の利害関係者が抱く懸念にアーキテクチャがどのように対処するかを示します。
viewpointsは、1 つのタイプのビューを構築するためのパターン、テンプレート、および規則のコレクションです。 それは、その見解を構築するための視点、ガイドライン、原則、およびテンプレート モデルに懸念を反映する利害関係者を定義します。
例えば、ITオペレーションズチーム向けにビューを作成する際には、オペレーションズビューポイントを使用します。このビューポイントは、システムの運用に関する情報が含まれるテンプレートです。オペレーションズビューポイントを使用することでシステムの運用に関係する人々に提供されるビューを作成することができます。
ITアーキテクトは、views、viewpointsの概念を明確に理解し、それらの違いとアーキテクチャを記述する際の連携方法を理解する必要があります。そしてIT開発プロジェクトで典型的なステークホルダーグループを識別し、各グループの典型的な関心事を理解し、特定のプロジェクトの要件を満たすために必要なviewのセットを決定する能力を持っていなければなりません。
「Views and Viewpoints」ではアーキテクトの主要な責任の1つは、関心を持つステークホルダーにシステムのビジョンを提示することと示されています。最も単純なシステム以外では、1枚の図で効果的にこれを示すことは不可能であり、したがってviewsとviewpointsの概念が開発されました。多くのアーキテクチャ記述法は、主要なアーキテクチャ情報を含む一連のviewsとして構成されています。多くのアーキテクチャフレームワークでは、システムの機能構造、主要なデータ構造、ソフトウェア開発方法、およびソフトウェアのデプロイ方法に関するviewpointsが含まれます。
viewpointベースのアーキテクチャフレームワークに多数のフレームワークが存在し、その中にはソフトウェア集中システム向けのものもあります。例えば、Kruchtenの4＋1アーキテクチャビューモデルやV&Bアプローチ、Software Systems Architectureセットなどがあります。
図. 4+1 architectural view model
出典：Wikipedia
以上の図はKruchtenの4+1アーキテクチャビューモデルですが、それぞれのモデルには以下のような関係性があります。
論理ビュー：論理ビューは、システムがエンドユーザーに提供する機能に関係します。論理ビューを表すために使用される UML 図には、 クラス図、 通信図、 シーケンス図などがあります。
開発ビュー：開発ビューはプログラマの観点からシステムを示し、ソフトウェア管理に関係します。このビューは実装ビューとも呼ばれます。 UML コンポーネント図を使用して システム コンポーネントを記述します。開発ビューを表すために使用される UML 図には、パッケージ図が含まれます。
プロセス ビュー：プロセス ビューはシステムの動的側面を扱い、システム プロセスとその通信方法を説明し、システムの実行時の動作に焦点を当てます。プロセス ビューは、同時実行性、分散、インテグレータ、パフォーマンス、スケーラビリティなどに対応します。プロセス ビューを表す UML 図には、 アクティビティ図が含まれます。
物理ビュー：物理ビューは、システム エンジニアの視点からシステムを表します。これは、物理層上のソフトウェア コンポーネントのトポロジと、これらのコンポーネント間の物理接続に関係します。このビューは、展開ビューとも呼ばれます。物理ビューを表すために使用される UML 図には、 配置図が含まれます。
シナリオ：アーキテクチャの説明は、小さな一連の ユースケース、つまり 5 番目のビューとなるシナリオを使用して説明されます。シナリオは、オブジェクト間およびプロセス間の一連の対話を記述します。これらは、アーキテクチャ要素を特定し、アーキテクチャ設計を図示して検証するために使用されます。これらは、アーキテクチャ プロトタイプのテストの開始点としても機能します。このビューは 、ユース ケース ビューとも呼ばれます。
そのほかにもアーキテクチャを具現化、視覚化する「Views and Viewpoints」の解説がIASA GlobalのWebサイトに載っておりますので、原文を参照してみてください。
ITアーキテクトに限らずですが、システムを開発する、運用する、保守する、プロジェクトを推進する等の様々な場面でシステムを可視化した資料は重要になります。システムの視覚化は1つの観点だけでは十分ではなく、さまざまな場面やステークホルダーによっても使い分ける必要があり、あくまでそれを見る人が中心でなければなりません。このため「Views and Viewpoints」では様々な手法や視点を取り上げつつ、それらを組み合わせ、使い分けすることが必要だとしています。
Iasa日本支部では情報交換や勉強会の場を設けており、システムの視覚化についても研鑽を深めていますので、今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします！
Comments