レガシーな組込みソフトウェア改良のための支援ツール

阪井*1*2，久保田*3，沖田*3，松本*2，鳥居*2

*1 株式会社SRA

*2 奈良先端科学技術大学院大学

*3 オムロン 株式会社

長期間使い続けられたソフトウェアは，まるで遺産のようである

（価値は高いが，保守が困難)．

• 機能の追加や変更など，改造が繰り返される．

• 多くの仕様を実現しており，価値は非常に高い．

• 保守性が徐々に悪くなり，改造が困難になっている．

→ 保守性の改善が必要である．

Legacy(遺産的）なソフトウェアの特徴

レガシーなソフトウェアの改良

• レガシーなソフトウェアを改良をするためには，ツールが必要である．

– 必要な工数とソフトウェアの余命を考えると新たに作り直せない．

– 限られた工数で効率良く改良したい．

– 一般に保守にはツールが必要である[1]．

[1] G. Canfora, A. Cimitile, U. D. Carlini, An Extensible System for Source Code

Analysis, IEEE Trans. On Software Engineering, Vol.24, No.9, pp.721-740, 1998.

組込みソフトウェア

– 機器(商品)に組み込まれている．

– マーケティングの観点(ｼｽﾃﾑ移行時期，競合他社)から，開発期間短縮の圧力が強い．

– 以下の内容を不揮発メモリーに保存する必要があり外部変数として実現されている．

• 機能ごとの動作モードの設定内容

• 障害発生時の復旧情報になる処理内容

→ これらの特徴が改造を困難にしている．

目的

• レガシーな組込みソフトウェア改良のための支援ツールを作成する．

– 改良に適した市販ツールが無い．

• 外部変数に関してはクロスリファレンスの機能しかない．

• 導入時のコスト(購入，ｲﾝｽﾄｰﾙ，教育)が高い．

• 汎用ツールであるため，必要とされる機能以外の教育コストがかかる．

→オープンソースのツールであるRubyとECTAGSを利用して支援ツールを作製した．

目次

背景

調査

分析支援ツール

試行と導入の結果

考察とまとめ

背景

調査

分析支援ツール

試行と導入の結果

考察とまとめ

調査

– Ｃ言語，6,748ファイルを対象とし，3Stepで調査した．

Step１:保守の困難なところを，エキスパートにインタビューした．

• 修正が繰り返され，

• データの判定が多いところ．

Step2:条件分岐を多く含む関数を調査した．

• すべての関数が保守性が悪いと限らない．

Step3:保守性の悪いプログラムを調査した．

• 多くの外部変数を参照する．

• モジュール構造が複雑である．

多くの外部変数を参照する場合１： 類似した外部変数の増加

– 既存の処理に影響を与えないように類似の外部変数が増えていった．

– 外部変数の統合が必要

ABCDE

ABCDE

ACDE SB S

SB A A

A

新規作成時 保守性の悪い状態 外部変数の統合

ACDEをＳに統合

関数で参照する外部変数

多くの外部変数を参照する場合２： データの流れの複雑化

–異なる種類の外部変数が多くあり，同種の判定が複数の関数に存在する．

–共通処理の抽出が必要

ABCDE ABE

ACDE CDE

A A A

A

新規作成時 保守性の悪い状態 共通処理の抽出

CD

AB AB

CDEの処理を抽出

下位関数の場合もある

多くの外部変数を含む場合２： データの流れの複雑化

下位の関数で参照する外部変数もインターフェースにしていると考えないと，共通処理をうまく抽出できない．

ABCDE ABE

ACDE CDE

A A A

A

新規作成時 保守性の悪い状態 共通処理の抽出

CD

AB AB

ABCDEと理解して抽出

モジュール構造が複雑な場合

–既存処理への影響をあたえずに，すでに実績のある処理を再利用しようとしていた．

–共通処理を分離する．

新規作成時 保守性の悪い状態 共通処理の分離

共通処理を分離

関数の呼び出し

改良に必要な情報

– 外部変数を統合した場合の参照の様子．

– 外部変数をインタフェースとして，下位の関数で用いられるものを含めたデータの流れ．

– 関数の呼び出し関係．

– 上記を組み合わせて，わかりやすく見渡せる情報．

背景

調査

分析支援ツール

試行と導入の結果

考察とまとめ

支援ツールの開発

オープンソースのツールであるRubyおよびECTAGSを利用して支援ツールを開発した．

– 外部変数を統合して表示する．

– 外部変数をインタフェースとして，下位の関数で用いられるものを含めて表示する．

– モジュール構造と共に表示する(関数と引数)．

– 導入のために設計ガイドを作成した．

– 保守性を維持するためにチェックリストを作成した．

見つける

直す

維持

ツールを内製した理由

– オープンソースのツールを利用して，内製すれば以下の効果があると考えた．

• オープンソースなので，社内に展開した際のコストが要らない．

• 最適で機能が限定されたツールを，少ない工数(約1,000step,約１人月)で開発できる．

• 機能が限定されているので，ツールの使い方を通して，保守性の維持に必要な内容が理解できる．

図 1　ツールの構造

ECTAGS

test_1st(+DXpass, +TLsrams, TLzensrams)

test_2nd(+DXpass, TLsrams, +TLzensrams)

test_3rd(DXpass, +TLzensrams)

[再]test_1st(DXpass, TLsrams, TLzensrams)

test_B(+DXpass, +TLsrams, TLzensrams)

[既]test_2nd(+DXpass, TLsrams, +TLzensrams)

ソースファイル

外部変数分類定義

ツール

Ruby関数定義情報

関数および

外部変数参照情報

出力

ツールの構造

背景

調査

分析支援ツール

試行と導入の結果

考察とまとめ

試行

– 約5,500ステップのソースプログラム

– エキスパートが８時間レビューした．

– 未経験者が，ツールを用いて30分調査した．

– レビューで発見できなかった問題点を発見することができた．

レビューで見つけられた問題の全てを，見つけることはできなかったが，コードレビューの抜けを少なくできた．

導入

• レガシーソフトウェアを改造して，新しいシステムを作るプロジェクトに導入した．

• 中心メンバー３～４人で2時間ずつ，５回の勉強会を実施した．

• 導入後，最終テスト段階でアンケートを実施した．

アンケート結果

• 修正元ソースの悪い構造が見えたので，元々開発された時と同じ構造にならないように参考にできた．

• 設計時に「保守性の高いソースを作る」という意識で開発・レビューできた．

• 元のプログラムに比べ，データを隠蔽したり，シンプルな構造にすることができた．その効果はその後の保守で実感した.

• 勉強会の実施により，知識が向上した．

• キャラクタインターフェースなので,あまり使わなかった．

• プログラム構造を大幅に変更する事が恐かったので,直接コードを見てレビューをした．

背景

調査

分析支援ツール

試行と導入の結果

考察とまとめ

考察

– 支援ツール導入の効果はあった．

– リーダーの評価は高かった．

• 改良方法が分かる．

• 改良後の構造を確認できる．

– メンバーの評価は低かった．

• 悪いところを見つける手助けはするが,修正作業そのものを支援しない．

– ユーザインターフェースの改良が必要である．

– 改良作業の支援の検討が必要である．

オープンソースツールを用いた内製の効果

– 必要な情報を必要なフォーマットで得られた．

– スクリプト言語なので，保守が容易であった．

• 自モジュールでの参照を示す＋マークを追加した．

• 外部変数をグループ化しないモードを追加した．

• 再出したツリーを再展開しないモードを追加した．

• Rubyのデバッグ機能により，短期間にデバッグできた．

– 不具合の生じやすい部分をECTAGSで実現したので，少ない工数で実現できた．

– WindowsとUNIXの２つの環境で実現できた．

まとめ

– レガシーな組込みソフトウェアの特徴を調査し，改良を支援するツールを作製した．

• 改良すべき点の検討や改良後のソフトウェアの保守性の確認に有効であった．

• オープンソースのツールを用いることで．少ない工数でツールを作成できた．

• ユーザインタフェースの改良と改造作業の支援は，今後の課題である．

– アプリケーションのレジストリも外部変数と考えられるので，ﾂｰﾙの適用を検討する必要がある．