Pure Java と MWE2 - メトリクスによる比較

Abstract

先日のホワイトペーパーでは，モデルワークフローを Pure Java で記述せずに DSL を使うことで得られるメリットを，具体的な実装を基に示しました。

しかし，「設計思想としては優れているものの，採用のコストに見合う効果が得られない」そんなフーレムワークも，ソフトウェアの世界では，しばしば見られるものです。

本稿は，そのような疑念を払拭するために執筆されました。実存する Pure Java のモデル変換エンジンを題材に，部分的な MWE2 対応実装に対しメトリクス計測を行い，その結果を示します。

評価対象

先日のホワイトペーパーで例示した A-RTEGEN を利用します。

A-RTEGEN の全てを MWE2 に対応するのは不可能ではありませんが，それなりの工数がかかります。そこで今回は，CONTRACT フェーズのワークフローに相当する部分のみを MWE2 相当に修正して比較します。

また，TOPPERSプロジェクトから配布されている A-RTEGEN はビルドシステムのサポートが貧弱でメトリクスを取りづらかったため，PizzaFactory プロジェクトが拡張した版をベースとしています。この方針により，ソースコード行数など数値の厳密さは犠牲になっています。

A-RTEGEN は，モデルから自動生成されたソースコードを含み，ソースコード全体における割合も小さくありません。そこで，評価対象は全体ではなく，今回の修正で大きな影響を受けた3つの plugin bundle のみとします。

以上のことからから，本稿が掲げる全ての数値は，相対的なもの，または傾向を示すものと捉えてください。

本稿のための MWE2 対応に要した工数は，1人で3.5時間です。さらに時間をかければ，さらに MWE2 にとって有利な(つまりMWE2を採用した顧客が得られるメリットが高い)数値を引き出せます。しかし，過度にチューニングしすぎた数値を提示しても現実と乖離してしまいますので，本稿では，敢えて時間に制約をかけました。

循環的複雑度

まず，ソフトウェアの保守性を示す指標である 循環的複雑度 を比較します。

循環的複雑度は，可読性や改変のしやすさといったプログラマの生産性に関わる情報を示すだけでなく，”全網羅するために最低限必要なテストケースの数”という品質活動に必要な情報を示します。

テストケースの爆発は，ランタイム側で既に起きています。ランタイム側のテスト工数抑制を抑えるには，ツールに対する品質活動が欠かせません。この流れに伴って，ツール側のテスト工数も増大の傾向にあります。ツールの循環的複雑度の低減は，プロセス全体のテスト工数低減のために欠かせない課題です。

それぞれの plugin bundle における，総合・関数平均・クラス平均・ファイル平均の数値を比較すると，次のようになります。

Complexity : jp.ac.nagoya_u.is.nces.a_are.app

	Total	Function	Class	File
Pure Java	124	3.4	9.5	10.3
MWE2	90	2.6	8.2	7.5

Complexity : jp.ac.nagoya_u.is.nces.a_are.codegen

	Total	Function	Class	File
Pure Java	93	1.8	8.5	8.5
MWE2	91	1.8	8.3	8.3

Complexity : jp.ac.nagoya_u.is.nces.a_are.validation

	Total	Function	Class	File
Pure Java	55	1.5	7.9	7.9
MWE2	49	1.7	7.0	7.0

MWE2 を用いた場合には，Pure Java に比べて循環的複雑度が低下する傾向が見られ，平均すると概ね 10% 弱程度の改善が見られます。

A-RTEGEN は，その背景にある AUTOSAR 仕様全体から見ると，RTE/Os/Schm という大事なソフトウェア部品を生成するツールであるものの，ツールという観点で見ると，他のランタイムコンポーネントのジェネレータに比べて格段に難しいことをしているというわけではありません。つまりテストに要するコストは，MWE2 を使ったか Pure Java で組んだかによって，少なくとも 10% 程度の差がでます。

ここで，思い出してください。本稿の調査は，もともとは MWE2 を想定していなかったコードを 1人が 3.5 時間だけかけ，最低限の修正をかけたものに基づいています。当初から MWE2 の存在を想定したコンポーネント設計を行っていた場合には，10% 弱の改善は，さらに良いスコアになります。

また，CONTRACT と GENERATE という2つのフェーズのうち，CONTRACT のみ修正していることにもご留意ください。全てを修正することで，10% 弱の改善に，2倍前後のレバレッジがかかることになります。

AUTOSAR のランタイムコンポーネントを全て揃えるためには，20億円以上の開発費が必要と言われています。それらのうちテストが占める割合は不明ですが仮に3割として，その20%といえば，その費用的効果は実感して頂けるのではないでしょうか。

ソースコード行数

MWE2 がテスト工数の削減に繋がり得ることは示しました。しかし，ソースコードの冗長性はどうでしょうか。定性的に，フレームワークを採用すると，その流儀に合わせるためのコードが増え，ソースコードの量が増える傾向にあります。

LOC 実測値(コメントや空白行を除いたソースコード行数)を示します。

Lines Of Code

artifact-id	Pure Java	MWE2
jp.ac….app	660	508
jp.ac….codegen	467	461
jp.ac….validation	323	553

validation で行数が増えているのは，フレームワーク採用による弊害です。この行数増加は抑制することも可能ですが，MWE2 スクリプトの作者のスキルレベル次第では，抑制し過ぎると使い勝手が悪くなるというトレードオフも存在します。

validation 以外の2つのバンドルに関しては，フレームワーク採用の割に，むしろ減っています。 MWE2 がワークフロー処理を肩代わりしたことによって，この現象は説明付けられます。

まとめ

ワークフローエンジンを採用した場合の保守性について，具体例を基に概説いたしました。また，コード行数の増減についても軽く触れました。

モデルワークフローをともなうプロセスにおいて，ツールを Pure Java で作成するか MWE2 のようなワークフローエンジンを採用するかは，そのモデルやプロセスの規模感に大きく依存します。 AUTOSAR のような大規模なモデル仕様ならば MWE2 の採用を強くお勧めします。しかし，アジャイル・プロトタイピングのように初期の小規模な取り組みであれば，Pure Java を選択する余地はあるのかもしれません。

MWE2 は，モデルワークフローの構築に大きなメリットをもたらしますが，MWE2 単体をインストールしただけではシステム構築は困難で，Eclipse プラグイン開発，EMF/ecore，Xtend/Xtext 等々の幅広い知識が必要となります。(いったんシステムが構築されてしまえば，利用者には深い知識は不要です)

合同会社もなみ屋では，Eclipse に関する10年の知見を，モデリングワークフローを構築しようとしている団体/企業に提供しています。ご興味をお持ちの方は，弊社サポート窓口まで電子メールにてお問い合わせください。

Abstract

評価対象

循環的複雑度

ソースコード行数

まとめ

広告