ISO/IEC/IEEE 42010での「観点」関連の用語の定義・用例

テストでは観点という言葉が時々使われています。ただ結構曖昧な用語なので、議論すると話が発散しがちな印象を持っています。
そこでは体系だった標準を土台にすると発散を軽減できる場合があるのですが、テストの観点を語る上で使えそうな標準として、ISO/IEC/IEEE 42010があります。

ISO 42010は、アーキテクチャ設計を対象にConcern(関心事)、Viewpoint(観点)、View(側面)の定義や関係性を規定するものです。
この規格は書いてある通りに従えば良いというものではないものの、Viewpoint、Viewなどの言葉の定義の共有手段として使えます。
またアーキテクチャ設計についての文献では、ISO 42010に則った解説や、ISO42010との関係性を明記した解説が結構あります。そのためアーキテクチャ設計の観点を学ぶ際の前提知識としても有用です。
テスト観点についての議論の助けになると思いますので、今回「観点」の用語に絞ってISO 42010について触れたいと思います。

用語

まずISO 42010で扱う用語を簡単に説明します。
留意点として、用語の対象はほとんどアーキテクチャについてです。本来「Architecture Viewpoint」「Architecture View」などと前後にArchitectureを明記しますが、自明であるとして規格では「Architecture」を省略しています。ここでもその省略表記に従います。

  • Concern(関心事)
    • システムに対するステークホルダ(システムに関わる個人や組織)の関心事。
    • 要求、制約、シーズ、製品リスクなどが該当する。
  • Model Kind
  • Model
    • Model Kindに従って表現したモデル成果物。
    • クラス図で構造を表現した成果物など。Viewの一種。
  • Perspective
    • 明示的に定義を行っているわけではないが、構造を横断する横断的Viewpointのような意味で使われている用語。
    • なお規格が引用している文献「ソフトウェアシステムアーキテクチャ構築の原理」では、ViewpointとPerspectiveを別の概念として区別している(前者は構造的に分けて考えられる観点、後者は構造を横断する横断的関心事、のように分けている)。

各用語の関係性

ISO 42010では前述の用語の関係性を「Conceptual model of an architecture description」という図でまとめています。そのうち、今回の解説に関係するものを抜粋すると、以下のようになります。

f:id:goyoki:20180403005221p:plain

関係性を大まかに説明すると次のようになります:

  • ステークホルダのConcernに対応するために、アーキテクチャを分析・設計します。
  • アーキテクチャの分析・設計を整理だてて行うために、整理・体系化されたViewpointを利用します。そこではViewpointごとにViewを分析し、得られたViewをArchitecture Descriptionとします。
  • ViewpointはModel Kindに関連付けられています。Viewの分析は、その関連付けされたModel Kindのモデルをモデリングする活動となります。

各用語の具体例

例えば給湯ポットの場合、具体例は次のような感じになります。

Concernの例

  • ポットの使用者のConcern
    • どれぐらい早く沸騰させられるか
    • 子供が誤って給湯できないようにするロック機能はあるか
  • 開発者のConcern
    • 開発をどのように分業できるか

Viewpointの例

  • 効率性についてのViewpoint
    • ハードウェアの資源効率性、加熱の時間効率性、・・・
  • 内部構造についてのViewpoint
    • ハードウェアとソフトウェアの責務分掌、ソフトウェアの構造、ソフトウェアの状態、・・・

Viewの例

  • Viewpoint「ソフトウェアの構造」に対するView
  • Viewpoint 「ハードウェアの資源効率性」に対するView
    • 「ROMサイズは128MByte以下である」
    • 「シングルコアである」

活用

ViewpointやViewをうまく体系化すると、次のような活用が可能になります。

  • 分析や設計の進め方についてのコミュニケーション(共有、レビュー、教授など)を容易にします。
  • View ModelとしてViewpointを整理しておくと、分析漏れに気づいたり、分析結果を整理したりするのに有用な事があります。
  • Viewpointを分けることで、複雑で大規模な分析を、分けて進められるようにします。

こうした活用を行っているものとしては、例えば開発プロセスのRUPやUPが有名です。