活用事例 こんな時に即効で効果を発揮します!
実行しない記述は見たくない!
Linuxの魅力の一つは、さまざまな命令セットアーキテクチャをサポートしていることです。Linuxカーネルのソースコードの中にはx86向けやARM向け、その他のプロセッサ向けのコードが混在しています。コンパイラは、開発者が指定したコンフィグレーション設定に従い、ターゲットに最適なソースを選んでビルドを行います。
つまり、Linuxカーネルのソースコードの中には、ビルド有効ソースとビルド無効ソース(ダミーソース)が混在しているわけです。そのため、開発者がソースコードを検索すると、多くのダミーソースが引っかかります。
Re:Zolverのリスト表示の機能を利用すると、オブジェクトに含まれるビルド有効ソースのみを画面に表示できます。わずらわしいダミーソースに悩まされることなく、所望の記述にすみやかにたどり着くことができます。
つまり、Linuxカーネルのソースコードの中には、ビルド有効ソースとビルド無効ソース(ダミーソース)が混在しているわけです。そのため、開発者がソースコードを検索すると、多くのダミーソースが引っかかります。
Re:Zolverのリスト表示の機能を利用すると、オブジェクトに含まれるビルド有効ソースのみを画面に表示できます。わずらわしいダミーソースに悩まされることなく、所望の記述にすみやかにたどり着くことができます。
新旧のソースを区別できない!
派生開発では、#ifdef文などのコンパイルスイッチを利用して、既存のソースコードの上に新しいコードを書き足していくことがよくあります。こうしておくと、ソースリスト上で新旧のソースを見比べることができ、開発者が保守しやすいという利点があります。
ただし、派生開発を繰り返していると、新旧のソースが入り混じり、コードの可読性が低下します。コードのどの部分が有効になっているのかを見極めることが難しくなります。
Re:Zolverのプログラム表示の機能を利用すると、ソースリストの中の有効行を簡単に識別できます。ビルドオブジェクトに含まれるソースの行番号を色分けして示します。
ただし、派生開発を繰り返していると、新旧のソースが入り混じり、コードの可読性が低下します。コードのどの部分が有効になっているのかを見極めることが難しくなります。
Re:Zolverのプログラム表示の機能を利用すると、ソースリストの中の有効行を簡単に識別できます。ビルドオブジェクトに含まれるソースの行番号を色分けして示します。
性能・メモリ不足を解消したい!
組み込みシステムの開発では、使用できるハードウェアリソースに制約があります。そのため、既存のシステムに新たな機能を追加する場合、処理性能やメモリ容量の不足に悩まされることがよくあります。コンパイルオプションの変更によってこれらの問題を解決できればよいのですが、解決できない場合は開発者自身がコードをチェックし、性能不足やメモリ不足の原因となっている箇所を洗い出す必要があります。このとき、場合によってはアセンブリ言語の命令列を確認しなければならないことがあります。
また、まれにコンパイラが開発者の意図と異なるコードを生成しているケースもあります。この場合も、アセンブリコードの確認が必要になります。
ただし、慣れていないと、こうした作業は大変です。ソースコードとの対応が分かりにくく、目を通すリストの量も多くなりがちです。
Re:Zolverのプログラム表示(MIX表示モード)の機能を利用すると、C/C++ソースリストの中に、ソースの各行に対応するアセンブリコードを混在表示させることが可能です。開発者は、一つのウィンドウの中で、着目するソースとアセンブリコードをつき合わせながらチェックできます。
また、まれにコンパイラが開発者の意図と異なるコードを生成しているケースもあります。この場合も、アセンブリコードの確認が必要になります。
ただし、慣れていないと、こうした作業は大変です。ソースコードとの対応が分かりにくく、目を通すリストの量も多くなりがちです。
Re:Zolverのプログラム表示(MIX表示モード)の機能を利用すると、C/C++ソースリストの中に、ソースの各行に対応するアセンブリコードを混在表示させることが可能です。開発者は、一つのウィンドウの中で、着目するソースとアセンブリコードをつき合わせながらチェックできます。
最適化の改善効果を知りたい!
組み込みシステム開発では、性能不足やメモリ不足などの問題を解消するために、さまざまな最適化を行います。例えば、コンパイルオプションを変更したり、ソースコードのレベルで関数のインライン展開を行ったり、マイコンが備える特殊な複合命令を活用したりします。また最後の手段として、アセンブリコードに手を入れることもあります。
しかし、最適化によってどのくらいの改善効果が見込めるかを、事前に予測することは容易ではありません。最適化のたびに実機による実行・検証を繰り返すと、それなりの時間がかかります。
Re:Zolverには、差分分析の機能があり、最適化前のオブジェクトコードと最適化後のオブジェクトコードを比較できます。例えば関数リストを表示すると、関数のコードサイズが、最適化の前後でどの程度変化したかを確認できます。
ASM表示モードを利用すれば、アセンブリ言語のレベルで最適化前後の差分を確認できます。
しかし、最適化によってどのくらいの改善効果が見込めるかを、事前に予測することは容易ではありません。最適化のたびに実機による実行・検証を繰り返すと、それなりの時間がかかります。
Re:Zolverには、差分分析の機能があり、最適化前のオブジェクトコードと最適化後のオブジェクトコードを比較できます。例えば関数リストを表示すると、関数のコードサイズが、最適化の前後でどの程度変化したかを確認できます。
ASM表示モードを利用すれば、アセンブリ言語のレベルで最適化前後の差分を確認できます。
バッファ変更の影響が予測不能!
TCP/IPなどのソケット通信では、受信データをバッファメモリに一時保存します。バッファサイズはグローバル変数で指定しますが、これをマクロで記述していると、バッファサイズを変更したときの影響を直感的にイメージすることが難しくなります。また、このマクロを多くのソースファイルで使用していると、サイズ変更の影響を予測することはますます困難になります。
Re:Zolverの変数リストを確認すると、マクロ展開後の変数の実サイズが分かります。バッファサイズ変更時の見通しがよくなります。
Re:Zolverの変数リストを確認すると、マクロ展開後の変数の実サイズが分かります。バッファサイズ変更時の見通しがよくなります。
工数見積もりで失敗したくない!
開発マネージャの悩みの一つが、派生開発の工数見積もりです。派生開発では、記述のわずかな変更がプログラム全体に影響を与えたり、予期せぬ箇所で副作用が生じたりすることがあります。さらに、作業依頼者が必ずしも開発担当者と同じレベルで派生開発の工数や難易度を理解しているとは限りません。
Re:Zolverの関数/変数 影響グラフを利用すると、関数/変数を変更したときの影響範囲を視覚的に確認できます。派生開発の見えにくい部分が明示されるので、工数見積もりの精度が上がると期待できます。
Re:Zolverの関数/変数 影響グラフを利用すると、関数/変数を変更したときの影響範囲を視覚的に確認できます。派生開発の見えにくい部分が明示されるので、工数見積もりの精度が上がると期待できます。
設計書を効率よく作成したい!
チームで取り組む派生開発では、設計書などのドキュメントの整備が欠かせません。ドキュメントを作成するにあたっては、事前に開発対象の全体像を把握しておくことが肝要です。
C++言語限定の話になりますが、Re:Zolverはクラス分析の機能を備えています。オブジェクトコードの内部構造を分析して、クラス関連グラフやUMLクラス図を表示します。この機能を利用すれば、既存システムの全体像の概要を把握できます。
これらの画面をカットアンドペーストして得られる画像データは、派生開発の設計書を作成する際の参考図面としても活用できます。
C++言語限定の話になりますが、Re:Zolverはクラス分析の機能を備えています。オブジェクトコードの内部構造を分析して、クラス関連グラフやUMLクラス図を表示します。この機能を利用すれば、既存システムの全体像の概要を把握できます。
これらの画面をカットアンドペーストして得られる画像データは、派生開発の設計書を作成する際の参考図面としても活用できます。
変更箇所をすべて洗い出したい!
派生開発において、既存のソースコードに手を加える場合、事前にすべての変更箇所(変更点)を洗い出しておく必要があります。開発者は、ソースコードの文字列検索を繰り返しながら、ある箇所の記述の変更が別のどの箇所に影響を与えるかを、網羅的に調べます。
この作業は意外と煩雑です。例えば、影響する箇所の数が非常に多かったり、多数のソースファイルにまたがっていたりすることがあります。検索を繰り返す過程で、見落としや勘違いなどのミスが生じることもあります。
Re:Zolverの関数/変数 影響グラフや関数/変数 影響リストを利用すれば、このような非効率な検索作業から解放されます。着目する箇所のノード(関数や変数)をクリックまたは検索すれば、変更の影響箇所をグラフやリストの形で確認できます。
この作業は意外と煩雑です。例えば、影響する箇所の数が非常に多かったり、多数のソースファイルにまたがっていたりすることがあります。検索を繰り返す過程で、見落としや勘違いなどのミスが生じることもあります。
Re:Zolverの関数/変数 影響グラフや関数/変数 影響リストを利用すれば、このような非効率な検索作業から解放されます。着目する箇所のノード(関数や変数)をクリックまたは検索すれば、変更の影響箇所をグラフやリストの形で確認できます。
担当者が退職、設計資料もない!
派生開発の案件の中には、十分な設計資料が残されていない、元の開発担当者が異動・退職しており連絡できない、というケースがあります。設計資料が残っていても、プログラムの追加・修正・削除やハードウェアの変更に伴う移植を繰り返した結果、システムの内部構造や記述が複雑になりすぎて、派生開発の担当者がコードを精査しきれない、というケースもあります。
Re:Zolverを利用すると、派生開発の担当者が既存のソフトウェア資産を分析する際の作業負担を軽減できます。システムの内部構造の概要は、関数/変数 影響グラフやクラス関連グラフから把握できます。
これらのグラフは、関数リストや変数リスト、ソースリストなど、さまざまなリスト表示の機能と連携動作するので、派生開発の担当者は、効率よく既存のコードの精査を進めることができます。
Re:Zolverを利用すると、派生開発の担当者が既存のソフトウェア資産を分析する際の作業負担を軽減できます。システムの内部構造の概要は、関数/変数 影響グラフやクラス関連グラフから把握できます。
これらのグラフは、関数リストや変数リスト、ソースリストなど、さまざまなリスト表示の機能と連携動作するので、派生開発の担当者は、効率よく既存のコードの精査を進めることができます。