前回のソフトウェアを腐敗させる６つの要素？Axivion Suite入門 その２では、ソフトウェアの腐敗につながる６つの要素について解説しました。
その要素のひとつアーキテクチャ違反・隠れ依存性という問題に対処するために、Axivion Suiteはアーキテクチャ解析という機能を提供しています。
本稿では、そのアーキテクチャ解析についてご紹介いたします！
おさらい：アーキテクチャ違反・隠れ依存性とは？
ソフトウェアのプロジェクトでは、リリースぎりぎりの修正や変更（いわゆるquick dirty fix)によって、ソフトウェアアーキテクチャに違反する実装がされることがあります。
（ここでは、上記画像の一番上のボックスから一番下のボックスにかけてつながっている、ギザギザのある矢印）
アーキテクチャ違反とは、基本的にはアーキテクチャ仕様に記載されていないソフトウェアコンポーネント間の依存性がソースコードに存在する状態を意味します。
言い換えると、アーキテクチャ仕様のソフトウェアコンポーネント同士の依存関係が、実際の実装上のソフトウェアコンポーネント同士の依存関係と一致していない状態です。
アーキテクチャ違反は隠れ依存性となってしまうリスクがあります。これは、プロジェクトのメンバーがだれも気付いていないアーキテクチャ違反を意味します。
隠れ依存性はアーキテクチャ違反よりもさらにタチがわるいものです。
大規模なプロジェクトでは特に、ソフトウェアに変更を加える際に、事前に影響箇所の分析のためにソースコードを読むのはとても非効率です。
なので、ソフトウェアコンポーネントの依存関係が定義されているアーキテクチャ仕様を確認して、「ここを変更したらここに影響がある。だからあそこを変更しよう」といった感じで変更計画を立てるのがよいのですが、
実はアーキテクチャ仕様と実装に相違がありましたとなると、アーキテクチャ仕様を信頼して計画した、安全かつ効率的と判断された変更が、実はソースコード上では、危険かつ非効率なものとなってしまう可能性があるのです。
また、この「隠れ依存性」のような「不透明性」は、そのほかにも余計な作業を引き起こしてしまう可能性もあります。（例えば、作りこんでしまった不具合の除去や、どこが違うのかはハッキリしないものの、アーキテクチャとコードが異なることが分かっている場合は、その目視によるレビューなど）
この問題は、アーキテクチャ仕様とソースコードを定期的にシンクすることで避けられるものであり、Axivion Suiteのアーキテクチャ違反/隠れ依存性チェックの機能を使えば、それを行うことができます。
概要
Axivion Suiteのアーキテクチャ解析では、ソフトウェアのアーキテクチャ仕様を活用します。
以下の図は、コンポーネントAがコンポーネントBに依存しており、コンポーネントBがコンポーネントCに依存しているというアーキテクチャ仕様を示しています。
Axivion Suiteは、実際のソースコードの構造を解析し、それをアーキテクチャ仕様と比較することで、一致していない箇所を特定します。
以下の図に見られるアーキテクチャ解析のアウトプットには、実際のソースコード(右)ではコンポーネントAからコンポーネントCに対して依存関係があり(赤色の矢印)、これがアーキテクチャ違反となっていることが示されています。
下図には記載されていないものの、アーキテクチャ仕様に存在するが実装に存在しない依存性（実装漏れ）も、検知された場合は黄色の矢印で表示されるので、実装漏れにも気づくことができます。
Axivion Suiteが発見したアーキテクチャ違反や隠れ依存性に対処する方法は３通りあります。
①ソースコードを修正し、アーキテクチャ仕様と一致させる
②アーキテクチャ仕様を修正する（アーキテクチャ仕様が誤っていた場合や、パフォーマンスなどの観点でソースコードの実装を正とした方がよい場合）
③デビエーションとして違反を一時的に受け入れ、将来の修正を計画する
このいずれの対応を取った場合も、アーキテクチャ仕様をベースにして信頼性のあるソフトウェアの変更計画を立てることが可能となります。
アーキテクチャという言葉が建築の分野から来ていることからもわかるように、ソースコードへの変更が行われる場合であっても、建築物を改築、増築するときと同じように、アーキテクチャ仕様を基にして変更を計画することで、全体への影響をみながら安全かつ最も効率的な変更を行うことができます。
これは、アーキテクチャ仕様と実装が一致していることを前提としているため、仮に両者に乖離があった場合、アーキテクチャ仕様を基に安全かつ効率的と判断された変更計画が、実際のソースコードでは安全でも効率的でもないリスクが生じてしまいます。
①、②の場合はアーキテクチャとソースコードが一致するので、アーキテクチャ仕様を正とした変更計画はソースコード上でも正となり、また③のアプローチをとった場合も、ソースコードにアーキテクチャとの相違があるというのは既知の事実であるため、その部分を考慮に入れたうえで変更を計画すれば、アーキテクチャ仕様を基にして安全かつ効率的なソースコードの変更を計画することができるのです。
アーキテクチャ解析に必要なもの
Axivion Suiteを使ってアーキテクチャ解析を行うために必要なのものは、以下の３つのいずれかです。
①アーキテクチャドキュメント（Word, PowerPoint, etc)
このほかにも、テキストファイルや、紙とペンなどであっても、何らかの形でアーキテクチャが設計されているケースです。
こういった、マシンリーダブルではない形式でアーキテクチャ仕様が存在する場合は、Axivion Suiteのアーキテクチャモデリングツールを使用して同一のアーキテクチャを作成することで、アーキテクチャ解析を行うことができるようになります。
②アーキテクチャモデル（CASEツール、XMI、XML、etc.)
既にCASEツールでアーキテクチャを作成している場合（Enterprise Architectや、IBM Rational Rhapsodyなど）は、それをAxivionにインポートして使用することが可能です。
また、そのほかにも、マシンリーダブルな形式で書かれているものであれば、カスタマイズしたインポート用のスクリプトを作成することでインポートすることができるようになります。
また、AUTOSARで使用するARXML形式のアーキテクチャもインポートすることができます。
③プロジェクトのアーキテクチャを理解しているメンバー
仮に、①も②も存在しない場合も心配はありません。アーキテクチャについて大まかな理解を持っているメンバーがいれば、Axivion Suiteのアーキテクチャモデリングツールを使用してモデルを作成し、実際にアーキテクチャ解析を実行して答え合わせを行うということを複数回イテレーションすることで、最終的にはソースコードと一致したアーキテクチャ仕様を作成することが可能です。（アーキテクチャリカバリーで後述）
アーキテクチャ解析の手順
アーキテクチャ解析を行うには、Axivion Suiteのアーキテクチャモデリングツール、Gravis（グラビス）にアーキテクチャモデルを作成する必要があります。
アーキテクチャモデルの作成が終わったら、同じツールにソースコードのフォルダ構成を読み込んで、モデル内のコンポーネントをそれぞれのソースファイルやフォルダに対してドラッグアンドドロップでマッピングしていきます。
マッピングが完了したら、解析を実行します。
解析が実行されると、Axivion Suiteがソースコードの構造を解析します。そうすることで、下図の右側のように、アーキテクチャモデルと実際のソースコードの差分が可視化されます。
アーキテクチャ違反や隠れ依存性は、以下のようにリスト形式でも確認することができます。
また、Gravisを使用してソースコードの問題個所も確認することができます。
アーキテクチャのインポート
CASEツールにすでにモデルが存在する場合は、そのモデルをGravisにインポートすることができます。インポートしたモデルは自動的にGravisの形式に変換されます。
<Enterprise Architectの例>
<IBM Rhapsodyの例>
アーキテクチャリカバリー
ソフトウェアのアーキテクチャ仕様そのものが存在しないことも多くあると思います。
そういった場合は、アーキテクチャリカバリーという手法を使うことで、アーキテクチャ仕様を作成していくことができます。
最初のステップとして、仮説に基づいてGravisでアーキテクチャを作成していきます。
作成したアーキテクチャモデルを使用して実際のソースコードに対してアーキテクチャ解析を実行することで、その相違点を把握することができます。
解析の実行によって明らかになった相違をアーキテクチャモデルにフィードバックして、再度解析を実行することを繰り返します。
このサイクルを繰り返すことで、最終的にはソースコードと一致したアーキテクチャを作成することができます。完成したアーキテクチャは、それ以降のソースコードの変更計画や、ソースコード実装後のアーキテクチャ解析に使用していくことができるようになります。
FFI(Freedom From Interference)を立証
安全基準(ISO 26262など）への準拠を求められるプロジェクトでは、異なるセーフティレベルを持つコンポーネントを含むソフトウェアを作成することが多くあります。
ここで、より高いセーフティレベルを持つコンポーネントには、開発時により厳しい基準が求められ（例えば、テストのカバレッジなど）、厳格に管理されますが、一方で、安全基準の対象外となるコンポーネントや、より低い安全基準に準拠を求められるものに関しては、そういった厳しい基準は求められないので、それ相応の基準に準拠しながら開発を行うことになります。
高いセーフティレベルを持つコンポーネントは、ソフトウェアの不具合が生じた際の被害がそれだけ大きいので、より厳格に開発を行う必要があるのです。
しかし、例えば、せっかく厳しい基準で作ったコンポーネントが、ほとんど制限なく作られたものや、より緩い制限のもと開発されたコンポーネントに処理を依存していたりすると、理論上は故障が起こりやすいコンポーネントの故障が、高いセーフティレベルをもつコンポーネントにまで影響を与えてしまうリスクが生じてしまいます。
エアバッグの挙動を制御するコンポーネント(セーフティレベル=高)あり、それがハイビームの挙動を制御するコンポーネント(セーフティレベル=低)の関数をコールしている場合を考えてみましょう。その関数がハイビームのコンポーネントの不具合によって全くリターンしなかったりすると、それがエアバッグの挙動にも影響を及ぼすことにつながりかねません。
これを防ごうというのがFFI(Freedom From Interference）で、より高い安全基準レベルを持つコンポーネントは、より低い安全基準レベルのコンポーネントもしくに対して依存関係を持ってはならないという考えです。
通常は、FFIが実現できているかの確認は、ソースコードの目視でのレビューによって行われることが多いですが、これには工数も多くかかり（定期的に実施する場合はなおさら）、さらに目視で行うことでミスが発生するリスクがあるので、あまり良い方法とは言えません。
Axivion Suiteのアーキテクチャ解析は、コンポーネント同士の依存度を機械的に明らかにするので、工数を下げながら確認の正確性を上げていくことができます。
おわりに
本稿ではAxivion Suiteのアーキテクチャ解析についてご紹介しましたが、いかがでしたでしょうか？
アーキテクチャ解析は、Gravisからだけではなく、Axivion Suiteの他の静的解析と同様にCI/CDシステムから定期的に実行することも可能なので、継続的にアーキテクチャとソースコードの一致を保証することもできます。
Axivion SuiteをはじめとするQtのQA(品質保証)ツールにご興味のおありの方は、Qt JapanのEメールアドレスjapan@qt.ioまでお気軽にご連絡ください。
概要のご説明から詳細な技術的相談、ツールトライアルのご案内もいたしております。
