Rational PurifyPlus によるランタイム分析入門

Rational PurifyPlus によるランタイム分析入門
Goran Begic
Technical Marketing Engineer, Development Solutions
--誰にも決して理解することができない人々がいます。ある瞬間、彼らは親切かもしれませんが、次の瞬間
不機嫌になり、怒り出します。そして、あなたが事態の収拾に努めようとすればするほど、状況は悪化していき
ます-開発中のソフトウェア・アプリケーションを理解することは、時としてひどく苛立たしい作業です。ある瞬間、一
見ポジティブな結果を生むように見えて次の瞬間に暴走することがあるからです。しかし、ソフトウェアのふる
まいを理解することは、上記のような気まぐれな人々の精神を理解するほど困難なことではありません。「ラン
タイム分析」の実施により、これが可能となります。
ランタイム分析は、特に新しい用語ではなく、長い間使われています。しかしながら、その言葉はソフトウェア
開発活動に隠れており、明確な定義や充分な説明がされていませんでした。本文では、Rational のベスト・プ
ラクティスにおけるランタイム分析の説明を行い、ソフトウェア開発者、テスター、マネージャーに対して、その
非常に大きな利点について概説します。
ランタイム分析とは何か？
まずは単純な定義から始めましょう：ランタイム分析は、コンポーネント実行間に収集されるデータを用いて、
ソフトウェア・コンポーネントのふるまいを理解することを狙った実践です。
この言葉自体は、実践時における主な要素を指しています：
ランタイム
は、開発したソフトウェア・ソースコードの静的解析や、ソフトウェアの基礎単位の関係を分析す
る方法を含んでいません。むしろ、開発されたコンポーネント（またはアプリケーション全体）が、実行時にどの
ようにふるまうかなどの重要な情報を、テスト環境又は最終的な実行環境において提供します。
分析
この活動は、数多くの顕在的又は潜在的に存在する、不正な実行結果に対する説明の提供を目的と
しています。「ソフトウェアの正常な動作を妨げているものは何か？」、「タイミング良く動作するのか？」、ある
いは、「ある特定の状況でエラーが発生するのはなぜか？」という質問に対して回答を提供するために利用可
能なデータおよび論理、知性、そしてソフトウェア開発に対する知識の結合が必要となるので、ユーザーは最
も重要な役割を演じることになります。
-1-
ランタイム分析は、次の側面におけるアプリケーション実行に関する知識を提供します：
実行パス
コード・カバレッジ
ランタイム・トレース
メモリー使用状況
メモリー・エラー、およびネイティブ・アプリケーションにおけるメモリー・リーク
Java アプリケーションと.NET が管理するコードで発生するメモリー・リーク
実行パフォーマンス
パフォーマンス・ボトルネック
スレッドにおける問題
ランタイム分析：デバッグの拡張
デバッグは、全てのソフトウェア開発者によって定期的に行われている、極めてありふれた作業です。
大抵の場合、ソースコードが正しい構文で書かれる限りアプリケーションは動作し、コンポーネントはエラーや
警告なしにコンパイルおよびリンクできると私達は考えていますが、実は、その仮定には誤りがあるのです！
なぜなら、たとえコンパイラがエラーをレポートしなくても、まだアプリケーションを顧客に出荷する準備ができ
ていないかも知れないからです。一般的に、コードを書く際にはコンポーネントの基本機能をテストして、全て
の要求を満足していることを確認します。通常の場合、QA（Quality Assurance：品質保証）チームは開発サイ
クルの後期にテストを行います。そのような QA テストでは、しばしば主なユースケース・シナリオの機能に重
点が置かれます。もし、全ての主なユースケース・シナリオの機能が確認できたとしたら、アプリケーションは
顧客に出荷する準備ができているのでしょうか？
答えは、"まだダメ"です。あるシナリオの組合せ、又は、あるテストされていないシナリオにおいて、アプリケー
ションはあるコンピュータ上でまだクラッシュするかもしれません。そして、パフォーマンスに満足できないかも
しれません。全ての開発業務における課題は、顧客に不完全なコードを出荷する可能性を最小限に留めるこ
とです。それを可能にする最善の方法は、開発サイクルの初期にできるだけテストを実行することです。
ランタイム分析を、標準デバッグ・ツール及び非常に独特で困難な問題の解決を支援する手法の延長と考え
るのは、非常に有効です。
開発テスト中のデータ収集
アプリケーションの実行に関する全ての詳細なランタイム分析用データは、アプリケーションのテスト時に収集
されます。このテストは、開発者によるテストです：機能を実装するエンジニアは、開発したコンポーネント機能
を、ユニット・テスト又はコンポーネント・テストの実行によって、基本テストを実行します。又、ソフトウェア・ラン
タイム分析データは、アプリケーションの QA テスト間に収集できます。
アプリケーション内部に関する（可視的な）情報の収集が目標なので、この種のデータ収集はしばしばホワイト
ボックス・テストと称されます。一方、アプリケーション内容に対する洞察なしの機能テストは、ブラックボック
ス・テストと呼ばれています。ブラックボックス・テストを実行するテスターは、ランタイム分析ログおよびレポー
トに興味がないかもしれません。しかし、テスターはブラックボックス・テストを実行する間、ホワイト・ボックス・
テスト・データを収集することができます。そして、機能又はパフォーマンス問題を記述して開発者に報告する
目的のために、ホワイト・ボックス情報を使用することができます。
-2-
テスト中にテストシナリオを記録して繰り返し再生できる、Rational(R) Robot のようなテスト自動化ツールで収
集されたランタイム分析データを用いることによって、品質を高めることができます。また、異なる開発済みの
ソフトウェア・コンポーネントの反復テスト用に、同じユースケース上で収集したランタイム分析データを分析で
きます。このことにより、１つのソフトウェア反復開発においてだけでなく、製品品質に対して新しく追加された
変更の影響に関して、より良い知識を得ることができます。２つのコンポーネントの連続的な反復においてソフ
トウェアの品質が低下する場合、ランタイム分析データによって、原因となる機能又はコードの変更箇所を容
易に発見できます。
ソフトウェア開発ライフサイクルにおけるランタイム分析
ソフトウェアを開発する最善の方法について様々な主張がありますが、秩序立ったアプローチを使用すること
により、計画または役割のアサインなしの場当たり的なアプローチよりも高品質な結果を得ることができると私
は考えています。コードを実装する前に最初に設計を行い、機能を実装し、コードが機能する前にテストを記
述し、あるいはプロセス・ステップをスキップするかに関係なく、最終結果（開発されたコンポーネントまたはア
プリケーション）に対して機能テストを実施する必要があります。
最終的な製品がユーザーのニーズに適合するかどうかの保証は、必ず要求と関連している必要があります。
そして、より早期にデバッグ作業が必要になります。開発されたソフトウェアが手元にある場合には、いかにソ
フトウェアが予想外の挙動を示すかがが、おわかりいただけると思います。
信頼性の高いソフトウェアを供給するためには、アプリケーションがどのように実行されるかを正確に把握す
る必要があります。この知識は、アプリケーションの論理だけでなく、そのパフォーマンスとメモリーに対する考
察も含む必要があります。
要求を優先
要求は、しばしば機能に集中します。
しかし、多くの人々が使用する…Rational(R) RequisitePro(R)のような…Rational の自動要求管理ツールは、
内部あるいは顧客のアプリケーションに対する考え方の両面から、アプリケーション品質を保証する要求を確
立するために重要であると認識されています。
たとえば、そのような 2 つの要求は、次のように記述されます：
サーバー・コンポーネントは、各クライアント・セッション前後に同量のメモリーを使用する必要がある。
そして
ユースケース・シナリオ#13 の前後でアプリケーションが使用するメモリーは、同量でなければならない。
これらの要求の両方とも論理的に聞こえるでしょう？しかし、私はどちらの条件も満たさないアプリケーション
を、長年見てきました。これはメモリー・リークが原因かもしれませんが、最終的な製品品質およびベンダーの
評判をひどく傷つけることになるでしょう。極端なケース（例えばサーバー側にあるコンポーネントのメモリー・
リーク）では、アプリケーション…または全てのシステム…がクラッシュする原因になりさえします。幸いなこと
に、あなたはメモリー・リークを発見するためにランタイム分析を開発中に用いることができます。そして、これ
らの要求を満たした高品質の製品の提供が可能となります。
-3-
極めて重要な品質要求に関する別の事例があります：今回は Web アプリケーションが対象です
ユースケース・シナリオ#91 用のコンポーネントの応答時間は、5 秒以下でなければならない。
繰り返しますが、ランタイム分析は、要求を満たしていることを保証する場合に役立ちます。
（それを行わない場合、ソフトウェアのユーザーは、その他の Web サイトにある情報を探し始めてしまうことで
しょう）最後に、極めて重要なテスト用の要求事例がここにあります：
QA チームが、利用可能なソースコード・ベースの 60%以上をテストしない場合、ソフトウェアはリリースの
準備ができない。
この要求は、取るに足らないものに聞こえるかもしれませんが、ちょっと考えてみて下さい。
過去に製品をリリースした際に、アプリケーション中のコードがどの程度テストされ、どの程度のコードが、エン
ドユーザーによる毎日の作業で「テストされる」ために残されているかを把握しているでしょうか？
ランタイム分析を行うことによって、ソースコードが完全にテストされたことの保証が可能になります。
ソフトウェア・モデリング
私は、個人的にはできるだけ早くからコーディングを行い、大規模な開発グループよりむしろ小さなチームで
働きたいと考えています。しかしながら、私自身のソフトウェア開発プロセスにおいて、アプリケーション中の最
も重要なシナリオやインターフェース、そして再利用するレガシーコードの依存関係を文書化することから始め
なければならないことを理解しています。
実際の作業をするためには、多分私は紙又はピカピカの新しいタブレット PC を使用できるでしょう。そして、自
分にしかわからない記号を使って、クラス図やシーケンス図を描き始めます。しかし、それが重要な開発プロ
ジェクトである場合、Rational Rose(R)、Rational Rose(R) RealTime または Rational(R) XDE.TM のような、統一モ
デリング言語（UML）を使用した自動モデリング・ツールの支援を得ることができます。そして、自分だけでなく
同僚、マネージャー、最終ユーザーにも簡単に理解できるモデルを作成することができます。これらのモデル
は、開発チームにおける役割を定義するために活用できるもので、グループに与えられた要求を満たすアプリ
ケーションの文書化を行います。また私は、"絶対に必要である機能" の基準に基づき、コードからモデルを
更新することができます。一体どこでソフトウェア・モデリングはランタイム分析と出会うのでしょうか？理論上
は、いくつかの交差点が想像できます。しかし、ここはランタイム分析が解決する 1 つの一般的な問題に焦点
を当ててみましょう。
実在するコード用のシーケンス図を作成することは、ひどく面倒です。シーケンス図を効果的に作成するため
には、アプリケーションがどのように実行されるかを正確に把握する必要があります。…ここは、ランタイム分
析が一番効果を発揮するところです。Rational(R) PurifyPlus for Linux そして Rational(R) Test RealTime 製品フ
ァミリーは、ランタイム分析情報を使用してテストの実行中に"その場"で UML のシーケンス図を作成するユニ
ークな機能を提供しています。（図 1 参照）
-4-
図 1：Rational PurifyPlus for Linux によって作成された UML シーケンス図
この独特な機能…ランタイム・トレース…の利点がデバッグ時にあることは明らかです：
デバッガを用いてテストを行う際、オブジェクト（メソッド・コール）を視覚化して、例外をレポートします。
コードを書く：実装とデバッグ
計画された機能は、開発ライフサイクルのいくつかのポイントでコードに実装されなければなりません;
次に、このコードはユニット・テストを支援するコンポーネントか、独立型アプリケーションのデバッグ・バージョ
ンとしてコンパイル又はリンクされます。後期開発工程における機能上の欠陥を避けるために、基本機能から
始め、それから機能を追加して下さい。
同じことは、パフォーマンス、又はメモリー利用問題においても適用されます：
パフォーマンスやメモリーのボトルネックを早期に発見すればするほど、より容易にそれらを解決し、高品質の
ソフトウェアを提供することが可能になります。もし、コードを実装する前にテストを書く場合、コンポーネントの
機能性だけでなく、パフォーマンスやメモリー使用状況に関する検証ポイントを定義できます。これは、ランタ
イム分析が効果を発揮し始めるところです。
いずれにせよ、機能はテストされる必要があるので、ランタイム分析は、機能テストが実行される間に収集さ
れる情報に基づき、問題の根本原因に関する正確な情報を提供します。
全ての主要言語のホスト機能では、アプリケーション実行に関する付加情報の収集が可能です。
たとえば、"assert"や"trace"の様なプログラム言語の機能や例外処理用キーワードの使用は、アプリケーシ
ョンの実行中に何が発生しているか理解するのに役立ちます。又、タイミング用のシステム API も、パフォーマ
ンス情報の収集に役立ちますが、データ収集の手段としては役に立たない上、テストされたアプリケーション
のパフォーマンスに対して過剰な影響を及ぼします。
例えば、下記のサンプル・コードにおいて、"assert は"ある種の演算結果についてあなたがコードを作成した
という仮定を確証するか否定するものです。
FILE* p = fopen("WordDoc.doc");
-5-
assert( p );
何らかの理由でこのファイルが冒頭から失敗する場合、fopen()によりゼロの値が返されます。
この戻り値を"assert"しない場合でも、アプリケーションは実行を続けますので、実際に動作をしているファイ
ルがうまく動作したかは決してわかりません。
assert は、この例ではある種のメソッドが正しく機能することについての仮定をチェックしているだけであること
に注意して下さい。
より複雑な状況では、ある種のシナリオを簡単に見失い、間違った仮定をするでしょう。そして、それは結果と
してランタイム・エラーに終わります。
このデバッグ手法の長所は明らかです。しかし、同様にいくつかの不利な点も、存在しています：
まず、コード中の全ての単一条件に対して"assert"することはできません。なぜなら、それによってコードの実
行が遅延され、持続が困難になるからです。そして、その他の多くのエラーが、コード実行において特に目立
つこともなく発生します；
もし我々が今までに述べた全ての言語機能を組み合わせたとしても、充分ではありません。
時として、エラーの根本原因がアプリケーション実行の初期に発生するため、問題を突きとめるのが困難にな
ります。
以前に述べたように、コードからアプリケーションの性能を測ることも可能です。ここに実例を示します：
time = System.currentTimeMillis();
DoSomething();
time = System.currentTimeMillis() - time;
System.out.prntln("Measured time is " + time);
しかし、このプロファイリング・メソッドはアプリケーション全体のプロファイルを許さず、従来通り、特定のコード
行に触れずに各メソッドの詳細を知らせます。ユーザー・インタラクションなどは、同じコンピュータ上で実行中
の、その他のプロセスによって影響を受けるかもしれないので、収集された時間もまた、信頼することはできま
せん。より詳細で信頼できるパフォーマンス・プロファイリングデータを得たい場合は、Rational(R) Quantify(R),
や Rational PurifyPlus のような専門のパフォーマンス・プロファイリングツールが必要となります。
他の基本的なデバッグ・ツールは、Visual Studio のデバッガや GNU gdb デバッガなどがあります。
実質的に、コードのどんな行でもデバッガによってアプリケーションの実行を止めることができます。
又デバッガは、プロセッサにおけるアプリケーションの実行を凍結する特別な命令をブレークポイントと共にセ
ットしたコード行上のマシン命令を置換できるので、実行中のアプリケーションのオブジェクト、変数、関数スタ
ックそしてレジスタの内容を調べることが可能です。
しかし、デバッガはメモリーやパフォーマンスに問題があるかどうかを知らせてはくれません。
問題が存在することを予感している場合、その発見を支援します。
一方、Rational(R) Purify(R)や Rational PurifyPlus のような専門のランタイム分析ツールは、発生したエラーに
おける全てのメモリー・エラーを、全ての詳細と共に記録します。
そのために、メモリー違反が起こる正確な場所にブレークポイントが置かれるでしょう。又、記録されたランタイ
ム分析データを通じてアプリケーションの内容を実行後に調べることができます。
ランタイム分析は、デバッグから"あてずっぽう"を除去します！
ランタイム分析による先進のデバッグ
-6-
デバッグの主な目的は、欠陥の根本原因の発見と、アプリケーションのふるまいを理解することにあります。ラ
ンタイム分析は、伝統的なデバッグを補う新たな機能を提供します：
アプリケーション実行状態の視覚化
メモリー使用、パフォーマンス、コード・カバレッジを含む極めて重要なランタイム・パラメータの測定
ユーザー・コードにおけるエラーの検出
ランタイム動作の文書化
下記の機能を検証することになります。
アプリケーション実行状態の視覚化
この機能を理解するために、5 つの例を挙げてみました。
視覚化の事例 1：ランタイム・トレース
最初に、ランタイム分析ツール（Rational PurifyPlus for Linux は、ランタイム・トレースを行います）が、テストし
たアプリケーションの重要なランタイム構成要素を視覚的にどのように表現するかを見てみましょう。図 1 が示
すように、この機能によってユーザーはコードの中を調べることができると同時に、オブジェクト間の相互作用
も見ることができます。
図 1:Rational PurifyPlus for Linux によるランタイム・トレース
視覚化の事例 2：コード・カバレッジ
Rational(R) PureCoverage(R)（Rational PurifyPlus に含まれます）のようなツールを使用したランタイム分析は、
コード・カバレッジ情報に対して様々なビューを提供します。それらの 1 つが、注釈付きソースです。この特定
のビューは、検査されたアプリケーションのソース・ファイルを示します：行の色は、テストケース実行後の実行、
-7-
未実行、部分的な実行といった、行の状態を示します。図 2 が示すように、ユーザーはテストケースに対する
コード・カバレッジや実行パスを見ることもできます。
図 2： Rational PurifyPlus による、Visual Studio.NET における C#.NET アプリケーションにおける注釈付きソースの表示
図 2 のコード・フラグメントは、アプリケーションの第 111 行でスイッチ文が実行された正確なパスを示していま
す。第 122 行が部分的にしか実行されなかったので、この特定の行はマークされました。
視覚化の事例 3：スレッド
Quantify（Rational PurifyPlus に含まれます）のようなランタイム分析ツールは、デバッグ中に各スレッドの状態
をマークすることにより、マルチスレッディング問題の発見などの、スレッドを視覚化する機能を提供します。図
3 が示すように、スレッドの視覚的なステータスをデバッグ中に調べることができます。
図 3：Visual Studio 6 における Rational Quantify によるスレッド解析ビュー
-8-
視覚化の事例 4：コール・グラフ
ランタイム分析ツールでは、パフォーマンス・ボトルネックの発見および表示が可能です。
従来の手法と比較した場合、このアプローチによる大きな長所は、シナリオ中に含まれるメソッドのコール数
に関する正確な情報だけでなく、実行パスの優れた概要を得られる点にあります。
図 4A と 4B が示すように、Rational Quantify のコール・グラフは、実行パスにおいて最も時間のかかるコール・
チェインをハイライト表示しています；そこがパフォーマンスのホットスポットです。
メソッド間をつなぐ細い線は、時間（Purify を使用している場合には、メモリーになります）がコール・チェイン間
と残りのアプリケーションでどの様に消費されているかの値に比例しています。
図 4A：Visual Studio .NET と VB.NET および C#.NET の混在したアプリケーションにおける Rational Quantify のコール・グラフ
図 4B：Solaris の C/C+++アプリケーションにおける Rational Quantify のコール・グラフ
視覚化の事例 5：メモリー使用状況
メモリー・リークを扱う最初のステップは、まずそれらを発見することです。
これを行うための、1 つの非常に直観的な方法は、全体的なメモリー使用状況を視覚化し、テスト
-9-
（ProgramUnderTest）中においてプログラム中のメモリーのスナップショットをとることにあります。
これにより、アプリケーションを実行する際に潜在するメモリー・リークを見ることができます。
（この機能は、Rational Purify for Java および.NET が管理するアプリケーションで利用できます）例えば、サー
バーで実行されているコンポーネントのメモリー使用状況のスナップショットが、その全体的なメモリー使用状
況を示す場合、使用状況は各クライアントでのセッション後に増大します。そして、それはおそらくコンポーネン
トで発生したメモリー・リークです（図 5 を参照）
図 5：Windows 版 Rational Purify によるスレッド状態およびメモリー使用状況のオーバービュー
極めて重要なランタイム・パラメータの測定
視覚によるエラーの検出は、ランタイム分析のまさにその最初の段階です。
実行中に何が発生しているかについて、正確に把握する必要があります。
そのため、ランタイム分析は、アプリケーションの実行において重要なパラメータの正確な測定値を根拠としな
ければなりません：
ランタイム・パフォーマンス
メモリー使用状況
コード・カバレッジ
このランタイム分析機能を理解するために事例を見てみましょう。
測定事例 1：関数リスト・ビュー
関数リスト・ビューは、Rational Quantify（図 6 を参照）のようなランタイム分析専門のツールによって生成され
る典型的なランタイム分析ビューです。測定パラメータによって分類された、アプリケーション全てにおける重
要なメソッドやオブジェクトを表示します；これにより、開発者はどのメソッドがその時最も利用可能なメモリー
を使用したかを突きとめられるのと同様に、最も実行が遅い関数、オブジェクトの寿命についてコードの解析
が可能になります。
-10-
このビューは、メソッドに対するコール数、メソッドの中だけで消費された時間、選択されたメソッドで蓄積され
たメモリーと消費された時間、そしてそれら全ての派生メソッドに関する正確な情報を提供します。
図 6：Visual C++アプリケーションにおける Rational Quantify の関数リスト・ビュー
測定事例 2：関数詳細ビュー
Rational Quantify のようなランタイム分析ツールは、測定事例 1 に示された情報を、コールしているメソッドと
派生メソッド間の測定データの分布情報を含ませるために拡張することが可能です。
このことは、関数詳細ビュー（図 7）中に示されています。このビューは、パフォーマンスまたはメモリー・ホット
スポット…パフォーマンスまたはメモリー・ボトルネックの正確な原因を発見するのに役立つ情報…の原因とな
るコーラーや派生メソッドをハイライト表示します。
図 7：Visual Studio .NET（Rational XDE を使用）における Visual C#.NET アプリケーションの、Rational Quantify による関数詳細ビュー
測定事例 3：メソッド・カバレッジ・モジュール・ビュー
前にも説明しましたように、ある状況において…特に、利用可能なテスト・メソッド値を評価する時…テストにお
けるコード・カバレッジの割合を測定することや、一連のテスト後に、テストされなかった全てのメソッドをマーク
-11-
することは非常に有効です。Rational(R)PureCoverage(R)のような、テストされていず動かないコードに対する
テストされたコード（図 8）に関する正確な情報を提供するツールを用いて実行することができます。
図 8：Rational PureCoverage による、Visual Studio .NET（Rational XDE 使用）上に混在する#.NET、VB.NET アプリケーションの、メソッド・
レベルのコード・カバレッジ表示
ユーザー・コードにおけるランタイム・メモリー破壊検出
これは、ネイティブの C/C++アプリケーション用ランタイム分析が非常に得意とするところです。
ランタイム分析は、パフォーマンス、メモリー、スレッド、コード・カバレッジ・データを複数のビューで表示して問
題の発見を支援するだけでなく、ユーザー・コードにおいてエラーが生成/発生した正確な箇所を特定すること
が可能です。ランタイム・メモリー破壊の発見は、全てのプラットフォーム上でネイティブの C/C++アプリケーシ
ョンが適切に機能することと、それが高品質であることを保証するためには必要不可欠です。
ランタイム・メモリーを検出する Rational のツールは、Rational Purify、Rational PurifyPlus になります。
再び、いくつかの例を見てみましょう。
エラー検出例 1：Rational Purify のメモリー・エラーおよびメモリー・リーク・レポート
Rational Purify は、開発者がメモリー・エラーを作成した正確な命令行を特定することができます。
この情報の提供には、ソース・ファイルを必要としません;
Rational Purify は、メモリーにおけるエラーを発見して、エラーの原因となる命令行（図 9 を参照）を突きとめる
ために、デバッグ情報を使用します。
-12-
図 9：Visual C++ アプリケーションにおける Rational Purify によるメモリー・エラーおよびメモリー・リーク・レポート
この例では、開発者は配列変数を構築する際に終了文字列を考慮することを忘れています。
デバッグ用にビルドされたものが申し分なく動作している一方で、このエラーは、リリース用にビルドされたア
プリケーションがクラッシュする原因になっていました。
この例は、ランタイム分析が C/C++開発におけるデバッグ時間を相当減らすことができる数多い方法の内の
一つです。
エラー検出例 2：Quantify による注釈付きソース
Rational Quantify には、命令行ごとに各ユーザー・メソッドに関して記録される時間の分布を測るためのユニ
ークな機能があります。Quantify による注釈付きソースは、各命令行の測定時間と共に、、各行でコールされ
た内部関数や消費された時間を表示します。この情報は、パフォーマンス・ボトルネックの原因を、個々の命
令行（図 10）に限定する場合に役立ちます。
図 10：Visual Basic 6 と Visual Studio 6 の Visual C++ が混在したアプリケーションにおける、Rational Quantify の注釈付きソース
-13-
エラー検出例 3：Purify のオブジェクトおよび参照グラフ
Java および.NET の管理するコードにおいては、ランタイム・サブシステムの自動メモリー管理機構が、割り当
てられたメモリーに開発者が直接アクセスするのを防ぎますので、領域を超えた読込や書込、そしてフリーメ
モリーの読込と書込のようなランタイム・メモリー・エラーは起こりえません。
しかしながら、この自動化されたメモリー管理は、オブジェクトに割り当てられたメモリーへの参照を、プログラ
マーが見落すことを防ぐことができません。
コードにおいて動的に割り当てられたオブジェクトに対する参照である限り、それらはメモリー中に留まり、自
動メモリー管理（ガーベジ・コレクター）によって削除されません。
そのようなエラーによる純粋な影響は、C/C++におけるメモリー・リークの場合と同じ位の影響があります：メモ
リーは、該当部分およびホスト上でオペレーティングシステムを実行している他の全てのプロセスで利用でき
なくなります。しかし、Rational Purify でランタイム分析をすることによって、問題のオブジェクトへの参照が作
成された（図 11）正確な命令行を特定することができます。
図 11：Java アプリケーションにおける Rational Purify のオブジェクト参照グラフ
ランタイム動作の文書化
更に、別の方法でランタイム分析に影響するのは、アプリケーションのランタイム動作を、先々のために文書
化することです。これは、プロジェクトの全体的な品質を評価し、新しく導入された機能やコード変更によるア
プリケーション全体のパフォーマンス、信頼性、テスト・ハーネスの完全性に対する影響を測定するのに役立
ちます。この先進的な実践ランタイム分析手法は、各コンポーネントの反復用のランタイム・データ収集や、プ
ロジェクト・ライフサイクルにおける異なる段階で、開発中のアプリケーションおよびデータの分析を実行するこ
とを伴います。この情報は、プロジェクト全体の品質と同様に、新たに追加された機能や、全体の品質に対す
るバグ・フィックスの影響に対して決定を下す場合に役立ちます。
Rational(R) ClearCase(R)のようなソース管理ツールと共にランタイム分析データを使用する場合、ソース・コー
ド・データベースにおけるどの変更が、不完全なビルド又は自動テストが失敗した原因であるかを容易に発見
できます；これにより、ソースコード・ベースのどの部分が、成功したテスト・セット、失敗したテスト・セット間で
変更されているのかについて理解することができます。それだけでなく、変更されたコードのオーナーや、それ
らが導入された正確な日時を特定することもできます。
-14-
例えば、複数のテスト・ランを分析する機能を提供する、Rational PurifyPlus のような先進的ランタイム分析ツ
ールは、様々なテストやテスト・ハーネスによるカバレッジ・データの結合や、図 13 に示すような、連続する反
復テストの測定を比較するために、データ・セットを別途作成することを可能にします。
図 13：Rational Quantify による実行レポートの比較
図 13 では、Rational Quantify で 2 つのデータ・セットを比較し、パフォーマンスが改善されたコール・チェインを
緑の行でハイライト表示し、パフォーマンスが低下した部分を赤い行でハイライト表示しています。計算データ
は、コールグラフ・ビューと、より詳細な関数リスト・ビューの両方で利用可能です。
仮に、自動テスト環境を作成する立場でなくても、ASCII ファイルで保存されるランタイム分析データを利用す
ることによって、データ分析を自動化することができます。図 14 は、Microsoft Excel にインポートされたパフォ
ーマンス・プロファイルの例を示しています。
図 14：Excel へインポートされた、Rational Quantify によるパフォーマンス・レポート
単純な Visual Basic アプリケーションを作成するか、あるいは Perl、WSH、JavaScript やその他の手頃なスクリ
プト言語によって、Excel で簡単にデータ分析を自動化することができます：
-15-
PurifyPlus for UNIX には、様々なテストから収集されたデータを管理・分析するのに役立つスクリプト・セットが
付属しています。
ランタイム分析：品質の重要さ
ランタイム分析は、標準的なソフトウェア開発活動を、品質に対する懸念という 1 つの重要な次元に沿って展
開することができます：開発中のアプリケーション内部の仕組みをよりよく理解することによって、より高品質な
ソフトウェアの開発を可能にします。
重要！：コンパイルされたソースコードは、品質を証明するものではありません;
詳細で高い信頼性を持つ、正確なランタイム・パフォーマンス、メモリー使用量、そしてスレッドおよびコード・カ
バレッジの測定データは、アプリケーションを重大なエラーから解放して、効率的に機能していることを確定す
るための唯一の方法です。
-16-