みなさま、こんにちは。
突然ですが、The Qt Companyが最近、静的解析ツールも扱い始めたことをご存じでしょうか？
そのツールは、名をAxivion Suite（アクシビオン・スイート）と言います。
本シリーズでは「Axivion Suite入門」と題しまして、少しでもこのツールについてご理解を頂けるような記事を書いていければと思いますので、どうぞよろしくお願いいたします！
そもそもAxivionとは？
Axivion Suiteは、もともとAxivion Gmbhというドイツ企業の静的解析ツールとして開発されました。
この会社は、ドイツの優れた工科大学連合「TU9」の１校として名を連ねるシュトゥットガルト大学が中心となって1996に行われたバウハウスプロジェクトという、ソフトウェアの保守やリエンジニアリングに関する学術研究にルーツを持ちます。2005年にそこから企業としてスピンオフする形で誕生してから、既に15年以上の歴史を持っています。
そんなAxivion Gmbhが、最近になってThe Qt Companyに買収されたことで、このAxivion SuiteはQtの扱う品質保障ソフトウェアツールのひとつとなりました。
Axivionを利用しているユーザー
そんなAxivion Suiteですが、現在その業界やソフトウェアの種類にかかわらず、様々なお客様にご愛顧いただいております。
使用される業界やソフトウェアの種類を選ばないことからソフトウェアの品質を気にかけている方なら、だれでも使えるツールと謳われています。
ソフトウェアの劣化を止める
Axivion Suiteのミッションは、ずばりソフトウェアの劣化を止める(Stop Software Erosion)です。
ソフトウェアの劣化。これは一体全体どういう意味なのでしょうか？
シュトゥットガルト大学は、今から２０年以上前にソフトウェア分析や複雑性に関する研究を始めました。
しかし、実はそれ以前の７０年代や８０年代の時点で、継続的に機能が追加され、進化、改善されていくソフトウェアシステムに対して何が起こるのかについて、すでに多くの研究がなされていました。
ここで、ある一定期間において開発が行われるソフトウェアがあるしましょう。
このグラフに対して、アプリケーションの機能の量をプロットするとすると、どのようなグラフができるでしょうか？
おそらく、機能の量は初期開発の時点でグンと増えるものの、そこからは機能の漸進的追加や改善がメインとなるため、その増加量は以下のように緩やかになるはずです。
では、ここにソフトウェアの複雑度をプロットするとすれば、どのような線になるでしょうか？
複雑度は、機能とは対照的に加速度的に増えていく傾向があります。
実際、これまでAxivion Gmbhが関わってきた顧客の95パーセント以上が、ソフトウェアの複雑度は、開発が進むにつれて非線形、もっとひどい場合は指数関数的に増加すると話しています。
そして、さまざまな産業においてソフトウェアの重要度が増加している近年においては、その様相はこれまで以上に顕著になっています。
問題は、ソフトウェアの複雑度には限界があり、その限界を迎えると、ソースコードの理解が非常に難しくなるということです。
複雑度がこの限界に達すると、新規機能の追加、既存機能の変更、新しいハードウェアへの移植などがとても困難になり、不具合（バグ）を作りこんでしまうリスクや、期限内に作業を終えられないリスクが高まってしまいます。
そして、仮にソフトウェアの複雑度が非線形で増加していく場合、ソフトウェアのライフサイクルが終わる前に、理解度の限界に到達してしまうのです。
この、開発の過程の中で増加する不要な複雑性によりソフトウェアの保守などに悪影響が及ぶことをソフトウェアの劣化と呼んでいます。
こういった事態に対する対応方法として、多くの場合定期的にソースコードのクリーンアップ、リファクタリングを行うという手段が取られます。
実際、Axivion Gmbhが当初とっていたアプローチも、こういったものでした。
しかし、そこには３つの問題がありました。
まず最初の問題は、このアプローチをもってしても、ソフトウェアのライフサイクルが完了する前に理解度の限界を迎えてしまうリスクがあることです。
そして２つ目の問題は、こういった定期的かつ大規模なリファクタリングは作業として単純に大変であるばかりではなく、大きなリスクが伴い、コストもかかることです。
第３の問題は、この大変で、大きなリスクが伴い、コストもかかる割に新機能が何も追加されない作業に対して、マネジメントの許可が下りないことです。
ソースコードの問題を認識していて、いくらリファクタリングを望んでいても、それがかなわなかったというエンジニアは星の数ほどいるはずです。
Axivionのアプローチ：継続的リファクタリング
Axivionのとるアプローチは継続的リファクタリングです。以下のグラフの緑の線のように、開発プロセスの一つとしてリファクタリングを組み込んでしまうことで、リスクやコストを抑えながら、マネジメントの承認も必要とせずにソフトウェアの複雑性を低く抑えることができます。
そして、上記の例ではプロジェクト開始時に継続的リファクタリングを開始していますが、このアプローチはプロジェクトの途中からでも開始することができます。
過去にも、このようにプロジェクトの途中からAxivion Suiteを使い始めて成果を挙げた顧客は多くいらっしゃいます。
継続的リファクタリングによってソフトウェアの劣化を防ぐためには、ソフトウェアの劣化の原因となる問題を特定し、それをどの程度まで抑えるのかを検討する必要があります。
次章ソフトウェアを劣化させる６つの要素？Axivion Suite入門 その２では、ソフトウェアの劣化の６つの原因についてご説明いたします。お楽しみに！
おわりに
以上が、記事の内容となります。
SquishをはじめとするQtのQA(品質保証)ツールにご興味のおありの方は、Qt JapanのEメールアドレスjapan@qt.ioまでお気軽にご連絡ください。
概要のご説明から詳細な技術的相談、ツールトライアルのご案内もいたしております。
TomCooksey: There is support for multiple rendering backends. Right now the solution would be to install your own QSGContext in the QSGView before showing it and reimplement the virtual QSGContext::createRenderer() function. For just sorting front to back, you can simply modify the sort function in the qmlrenderer.cpp, though.
Any updates? What is the feature parity/status with the regular branch?
And let it be said that:
I for one welcome our velvety overlords to the staging area.
The biggest change since switching from the previous repo, is the merge with mainline Qt/QML, which means a lot of bug fixes to the QML items and working input handling.
Will the Scene Graph be part of qt 4.8?
Oh heck yes! I'm all over this then! I'll try it t his weekend!
Everything is looking great. Thanks for the information!
Is there still support for multiple renderer back-ends? I was hoping to find some time fairly soon to learn the code base by playing with this on some Mali HW. Wanted to see how hard it is to traverse the scene graph and render the opaque items front-to-back (which has performance benefits for Mali). Is this still possible?
PS: Hi guys!!! ;-)
Do I have to grab the whole branch, or can I just grab the declarative directory?
When I try to browse it (http), it errors out (This Git object is too large to be displayed in the browser)
I usually just have it tar everything up and get it that way.
Any hints on what to do for better performance? With QMLSHOWFRAMERATE=1 I can see that the paintEvent takes >60ms on average. With the raster graphicsengine its <20. And it's not a very complex scene.
scorp1us: yeah, you need to pull the whole branch and check it out.
michael: I would be interested in what this scene contains and on which environment, because normally that is not what we see. We have only seen that on massive texture uploads, several mb''s pr frame, or when GL resorts to poor software rendering, but in general we see improvements in performance.
C:Qt>git clone git://gitorious.org/+qt-dev...
Initialized empty Git repository in C:/Qt/staging/.git/
remote: Counting objects: 531558, done.
fatal: The remote end hung up unexpectedly
fatal: early EOF
What am I doing wrong? It counts object at 50-25 per second.
I am not having any luck with checking it out.
Be it git protocol (where it says server closed connection)
or via HTTP:
error: Unable to get pack file http://git.gitorious.org/+q...
g.git/objects/pack/pack-64bdc54b212977013b5bfa98511b8edf2c7eef4f.pack
transfer closed with 116502980 bytes remaining to read
error: Unable to find 8a441f3cf8a2cbc92861b7c55dd4664da4e8130b under http://git.
gitorious.org/+qt-developer...
Cannot obtain needed object 8a441f3cf8a2cbc92861b7c55dd4664da4e8130b
while processing commit 8cb85d5cb47f06f01f70781e9762a716cabdc73a.
fatal: Fetch failed.
git is not winning me over. I'd also like to skip the whole repo and just pull the branch I need, which I can do in svn or perforce.