シュトゥットガルト大学の研究から始まった静的解析ツールAxivion Suite
Qt Groupは、"Code Once, Deploy Everywhere"のタグラインの下、1995年からクロスプラットフォーム開発フレームワークを提供してきた。開発プロセスの課題に応えるために品質保証ツールの範囲を拡大し、2021年にはfroglogicを買収して、GUIテストの自動化ツールであるSquish、コードカバレッジツールのCoco、そしてテスト結果管理ツールのTest Centerなどの製品ラインを強化した。さらに、2022年にはソフトウェア劣化を防ぐための静的解析とアーキテクチャ検証ツールを提供するAxivionを買収した。
インディ氏は20年以上にわたり、大手からベンチャーまでさまざまなハードウェアとソフトウェアの開発に携わってきた。2022年にQt Groupに参加し、ソリューションエンジニアとして、顧客がQt製品を最適に利用できるよう支援している。今回インディ氏は、Axivion Suiteにフォーカスしたプレゼンテーションを行った。
ドイツに拠点を置くAxivionは、15年以上にわたって静的解析ツールを提供している。この技術は元々シュトゥットガルト大学のバウハウスプロジェクトという研究プロジェクトから派生したものである。ソフトウェアアーキテクチャの深い理解を目的とした研究から始まり、その成果はやがて有償製品であるAxivion Suiteへと発展した。
Axivion Suiteは、自動車や医療、鉄道、電力など、さまざまな業界の安全機能の規格に対応している。世界中で200以上の顧客に利用されており、自動車や医療をはじめとする多様な業界での採用が進んでいる。日本市場においてはQt Groupが日本語によるローカルサポートを提供している。
典型的なソフトウェア劣化パターン6種類
続いてインディ氏は、ソフトウェアの劣化について話を向けた。ソフトウェアの劣化は、開発プロジェクトでよく見られる現象であり、新製品の開発時にはソースコードが比較的シンプルであり、正しいアーキテクチャを持ち、複雑化していないため容易に理解できる。しかし、機能の追加が進むにつれて複雑度が増し、設計が急速に複雑化し、人間が理解しづらい状態に陥る。すると、新たな機能の追加、エラーの修正、バグ修正のコストが大幅に増加する。これにより、計画された製品ライフサイクルが終わる前に製品の維持が困難となってしまう。
ソフトウェアコードの複雑さや複雑度が発生する背景には、複数の劣化の種類が存在する。インディ氏は、自動車のダッシュボードに温度を表示するシステムを例に紹介した。センサーが温度を摂氏で測定し、その後で単位の変換を行い、ダッシュボードのディスプレイに表示される仕組みだ。
単位の変換で、欧州向けは摂氏そのまま、米国向けには華氏にする処理が必要というアーキテクチャだったとする。しかしその間に展示会に出展することになり、時間的制約から摂氏から華氏への単位変換の処理が省略されてしまった。センサーの値がそのままダッシュボードに表示されるようなアーキテクチャ違反・隠れ依存性となった。
展示会には問題なかったものの、この違反を放置して米国向けに出荷する際に華氏への変換が行われないまま出荷されたとする。その場合、摂氏30度が華氏30度（摂氏-1.1度）と判断され「路面凍結注意」という不適切なアラートが表示されるような事態が発生する可能性がある。
インディ氏は、「アーキテクチャ違反・隠れ依存性を防ぐにはアーキテクチャ図を描き、その後の実装をこのアーキテクチャと比較する検証作業が必要」と説明した。解析ツールを用いれば、先のような単位変換が省略された違反が発見でき、適切な対処が可能となる。
アーキテクチャ違反に対処するため、検証をせずに急場しのぎで既存コードのコピー＆ペーストによる修正を行った場合、更なる劣化が発生し、アーキテクチャ違反だけでなく、冗長な処理が複数の場所に点在する隠れた依存関係が生じてしまう可能性もある。これは、「コードクローン」と呼ばれる、ある場所で正しく動作している処理を別の場所でも利用する行為によるソフトウェアの劣化だ。
コードクローン自体は悪いことではないが、バグが発生した際に影響する範囲が広くなることが問題だ。複数の箇所で同じようなバグレポートが生じ、複数回の修正を必要とすることになる。このような状況は、そもそもコピー＆ペーストを行わないか、行った場合でもどこで同じ処理が使われているかを把握してクローンを管理するシステムを利用することで対処できる。
続いてインディ氏はスタイル違反によるソフトウェア劣化について説明した。
#define Square(x) x*x
というC++コードに対して
Square(5) = Square(2+3) =
と、一見結果が同じになるような引数を与えた2つの式を提示した。
5を引数にする場合、「5*5=25」となるが、2+3を引数にすると「2+3*2+3=11」となってしまう。
これはスタイル違反であり、バグではないものの混乱が生じる原因になる。対処するには、以下のように正しい括弧の使用を要求するコーディング規約を定義し、使用する。
#define Square(x) ((x)*(x))
インディ氏は、典型的なソフトウェア劣化の種類は、前述したアーキテクチャ違反・隠れ依存性、コードクローン、スタイル違反のほかに3つあるとした。ファイル内に大量のコード行が存在する場合や、関数のネストレベルが多い場合に生じるメトリクス違反、記述されているが使用されていない処理であるデッドコード、関数およびモジュール間の循環依存だ。これら6種類の劣化に対処することで、ソースコードを元の清潔な状態に復元する、あるいは少なくともさらなる劣化を防ぎたい。
生産性を高める静的解析ツール「Axivion Suite」とは
Axivion Suiteはソフトウェア劣化を防ぐための静的解析ツールだ。静的解析とはソースコードを実行せずに解析する技術であり、動的テストとは異なり、部分的にしか実行できないコードや、呼び出し元が存在しないライブラリも解析できる。
静的解析にはさまざまな手法が存在する。抽象解釈は、ソースコードをモデル化し、その構造を理解するために用いられ、アーキテクチャの解析に役立つ。テイント解析（Taint Analysis）は、セキュリティ関連の解析で、特定の位置で変更されたデータを検出する。字句解析では、ソースコードをトークンに分解して解析する。データフロー解析では、ソースコード内のデータの流れを、実行せずにモデリングする。
静的解析ツール利用のメリットは、バグの早期発見だ。また、コーディング規約の適用によりコード品質を改善できる。機能安全性が求められるプロジェクトでは、MISRAなどの規約に準拠したコンプライアンスに配慮した検証も可能だ。さらに、脆弱性検出、メトリクスの測定・ドキュメント化、コードレビューの自動化など、多岐にわたる利用方法がある。ツールによる検証の効率化をすることによって、人間はより高度な判断が求められる部分に集中できる。
一方で静的解析は簡単ではなく、解析の複雑さ、処理の重さによる速度の遅さ、検出量の多さ、誤検出の存在、ツールのライセンス費用が高いなど、いくつかの課題がある。
これらの課題に対する対策としては、継続的インテグレーションシステムでの継続的な実行、差分解析による効率的なエラー修正、ローカル実行や単一ファイル解析による部分的な解析が考えられる。誤検出に関しては、速度と精度のトレードオフが避けられないが、適切なバランスを見つけることが重要である。
費用に関しては、導入コストと維持コストだけでなく、プロジェクトの全体コストを考慮することが重要である。インディ氏は、プロジェクトの初期開発コストは全体の開発コストの約20％を占めるとし、全体コストの約40％は既存ソフトウェアの理解に費やされているという統計を示した。そして、その4分の1は生産性の向上によって削減できるとした。
インディ氏は「出荷後のエラー改修コストが一番高いです。なるべく早くアーキテクチャの解析の段階で、対策をした方が安く済みます。解析ツールの導入費用とうまくバランスをとることができます」と説明した。
続いてインディ氏はAxivion Suiteの説明を行った。Axivion Suiteは、バージョン管理システムに格納されたソースコードに対し、継続的インテグレーションシステムと連携して動作する。開発者は統合開発環境（IDE）を利用しながら参照できる。WebインターフェースやレポーティングAPIも備えているので、アーキテクトを含むチームメンバーは全体の設計を見ながら開発者とコミュニケーションできる。
アーキテクチャ検証、クローン検出・管理、コーディング規約遵守、メトリクス監視、循環依存性解析、デッドコード検出など、主なソフトウェア劣化の要因に対処可能だ。
Axivion Suiteのダッシュボードでは、検証実行のたびに検出量の変化を追跡し、さまざまな種類の検出結果を可視化する。検出された問題の詳細や、ソースコード内での具体的な問題発生箇所、追加・削除された要素の情報も得られる。
ソースコードの詳細は図を用いても確認可能であり、循環依存性のような問題を視覚的に捉えられるようになっている。複雑さの指標も示し、アーキテクチャのモデリングツールでは正しい構造と違反を示すことができる。
インディ氏は最後に「皆様の製品開発に生じている複雑さや、問題点の解決を弊社が支援できると考えています」とコメントした。
