Reengineering Software Evolution Technology

ソフトウェア進化技術の実践に関する調査研究

• HOME
• メンバ
• 概要
• 公開資料(SSR会員のみ)
• 進化パターン集
• 活動の記録

プログラム理解支援パターン

　ソフトウェアシステムにおいて，実際に稼働している実体はプログラムである．このため，ソフトウェア進化を実現する際に，プログラムが唯一信用できる成果物と考える開発者や保守者は多い．また，実際の保守現場では，プログラムしかないという状況や，過去の変更が要求仕様書や設計仕様書に反映されていないという状況が頻繁に発生している．

　このような状況において，既存のソフトウェアシステムを改変するためには，実際に稼働しているプログラムを理解することが不可欠である．特に，リバースエンジニアリングにより，プログラムコードを解析することで，プログラム理解に役立つ情報を抽出することができる可能性が高い．このような観点から，OORP[7]の2〜5章では，全部で20個のリエンジニアリングパターンが紹介されている(OORP パターン2.1〜2.7，3.1〜3.5，4.1〜4.3，5.1〜5.5)．

　ここでは，OORPのリバースエンジニアリングパターンを補足する形で，プログラム理解に焦点を当てた3つのパターンを紹介する．

　このような状況を受け，ここでは， ソフトウェア変更を支援する5つのパターンを紹介する．

• パターン5.1 テストとモジュールの対応関係を作成しよう
• パターン5.2 マイクロブログを活用しよう
• パターン5.3 コードに付箋を付けよう

パターン 5.1

テストとモジュールの対応関係を作成しよう
Create a Mapping between Tests and Modules

既存のモジュールの利用法を理解したい．

問題

• ソフトウェアの保守・進化の際には，既存のモジュールを低コストで修正・再利用することが重要である．特に，モジュールごとの仕様，中でもAPIの使用方法を理解することが重要であるが，このドキュメントがそもそも存在しなかったり，存在しても内容が古くなってしまっていたりすることがしばしばある．当該モジュールの開発担当者と連絡できなくなっていることもしばしばある．
• APIの名前とシグネチャからおおよその使用法を推測し，実際にいくつかの入力を与えて出力を見ることで確かめる方法がある．しかしこの方法は非常に正確さに欠ける方法であり．元の開発担当者の意図をつかむことは難しい．別の方法として，ソースコードを精査して挙動を理解した上で使用方法を考えることもできるが，これは非常にコストが高い．

解法

• 当該モジュールを主なテスト対象としているテストケースを参照することで，モジュールの使用方法を大まかに把握できる．
• 当該モジュールの開発担当者は，そのモジュールが提供する機能を一通り把握しているはずであり，少なくとも機能ごとのテストは行うと考えられる．テストに書かれた入出力例は開発担当者の意図（当該モジュールの挙動だけでなく，使用のための前提条件も含む）が含まれているものであり，派生開発の担当者が試行錯誤してAPIの使用方法を調べるよりも確かな情報を把握できる．また，ソースコードを精査するほどのコストはかからない．

トレードオフ

-利点

• モジュールの大まかな使い方を手軽に理解できる．
• テストケースが正常系用か異常系用か判断できる場合は，想定されている入出力の範囲をある程度知ることができる．

• テストはあくまで例でしかなく，保証された仕様がわかるものではない．
• 十分な数のテストケースがそろっていなければ利用が難しい．

パターン 5.2

マイクロブログを活用しよう
Exploit Micro-Blogging

ソフトウェア改変において，設計意図を有効に活用したい．

問題

• 既存のソースコードを改変しようと考えた際，当時の設計意図が分からない．このような状況で，改変を行った場合，過去に取り消したコードに戻ってしまうことや暗黙の了解事項に違反するコードに変更してしまうことがある．
• 通常，コメントはそのソースコードに関する最終的な内容を記入し，設計経緯や設計判断を記述しない．コメントに設計意図を混在させるとコメントが読みにくくなる．また，コードに記述することで設計意図が外部に流出する可能性がある．
• ソフトウェアの寿命が長くなると，改変時に開発者を探しても見つからないことが多い．

解法

• 将来の改変のために，短い文章で設計意図を残しておく．その際，ソースコードに残す通常コメントと区別し，twitterのようなマイクロブログを活用するのが良い．
• マイクロブログを活用することで，保守者や開発者に対する質疑応答を機械処理できるようになる．これにより，設計意図を検索や推薦できる．
• ソースコードの内容に詳しいのは，そのコードを記述したプログラマである．また，通常，ソースコードに関する設計経緯や設計判断が存在しないまま，ソースコードが記述されたり，変更されたりすることはない．プログラマにとって，それを記述するのが面倒なだけである．

トレードオフ

-利点

• 設計の意図が復元でき，無駄な改変を避けることができる．

• 記述のためのプログラマの負担が増える．

実例

　GitHubなどのソーシャルコーディング環境では，コミットやコミットされたコードにコメントを付与することができる．

関連するパターン

　ソースコードの位置を指定したコメントが有用な場合，コードに付箋を付けよう (パターン5.3)の利用を検討せよ．

パターン 5.3

コードに付箋を付けよう
Attach Post-it notes to Code

ソースコードに一時的な情報を残したい．

問題

• 通常，コメントはそのソースコードに関する恒久的な内容を記入し，揮発的なメモやTODOなどの予定を記入しない．
• 恒久的な内容と一時的なコメントを同じ形式で混在させると，検索結果におけるノイズの発生確率が高くなる．
• マイクロブログやメールなどのメディアでは，ソースコードの特定箇所を指示するのが面倒である．ファイル名や行番号で位置を特定した場合，変更されたソースコードに対する位置を追従させるのが困難である．

解法

• メモやTODOを（開発環境で提供する）付箋としてソースコードに貼り付ける．これにより，ソースコードにおける位置の追従が容易になる．
• 不要になった付箋は簡単に削除することができるようにする．その際，ソースコードの変更には影響を与えないことが重要である．
• 理解作業や改変作業が休憩や翌日にまたがる場合に，付箋を作業の再開(resume)の参考に利用する．再開後に付箋は削除する．
• 付箋を特定のイベント（例えば，時刻，変数や関数の名前変更）に対応させて，付箋の表示（発火）を制御することができる．

トレードオフ

-利点

• 概念として慣れている（よく知られた）付箋を用いて，一時的な情報を管理できる．
• イベントドリブンなコメント機能が実現できる．

• 付箋を管理する特別な開発環境が必要になる．異なる環境で付箋情報を共有することは難しい．

関連するパターン

　本パターンは，コードと疑問を結びつけよう / Tie Code and Questions (OORP パターン5.1)の具体的な実現方法のひとつである．

参考文献

•   [1] M. M. Lehman, M. M., “Programs, Life Cycles, and Laws of Software Evolution”, Proc. IEEE, Vol.68, No. 9, pp. 1060-1076 (1980)
•   [2] 大森隆行, 丸山勝久, 林晋平, 沢田篤史, “ソフトウェア進化研究の分類と動向”, コンピュータソフトウェア, Vol.29, No.3, pp.3-28 (2012)
•   [3] W. M. Ulrich, P. H. Newcomb, “Information Systems Transformation: Architecture-Driven Modernization Case Studies”, Morgan Kaufmann (2010)
•   [4] D. L. Parnas, “Software Aging”, Proc. ICSE'94, pp.279-287 (1994)
•   [5] M. Jazayeri, “Species Evolve, Individuals Age”, Proc. IWPSE'05, 2005, pp.3-12 (2005)
•   [6] E.J. Chikofsky, and J. H. Cross II, “Reverse Engineering and Design Recovery: A Taxonomy”, IEEE Software, Vol.7, No.1, pp.13-17 (1990)
•   [7] S. Demeyer, S. Ducasse, O. Nierstrasz, “Object-Oriented Reengineering Patterns”, Morgan Kaufmann (2002) （ダウンロード）
•   [8] M. Fowler, “Refactoring: Improving the Design of Existing Code”, Addison-Wesley (1999)
  (訳) 児玉公信, 平澤章, 友野晶夫, 梅沢真史, “リファクタリング”, ピアソンエデュケーション (2000)
•   [9] パターンワーキンググループ, “ソフトウェアパターン入門”, ソフト・リサーチ・センター (2005)
• [10] P. Clements and L. Northrop, “Software Product Line: Practices and Patters”, Addison Wesley (2001)
• [11] K. Pohl, G. Böeckle, F. J. van der Linden, “Software Product Line Engineering: Foundations, Principles and Techniques”, Springer (2005)
  (訳) 林好一, 吉村健太郎, 今関剛, “ソフトウェアプロダクトラインエンジニアリング ― ソフトウェア製品系列開発の基礎と概念から技法まで”, エスアイビーアクセス (2009)
• [12] J. McGregor, D. Muthig, K. Yoshimura, P. Jensen, “Successful Software Product Line Practices”, IEEE Software, Vol. 27, No. 3, pp.16–21 (2010)
• [13] K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, A. S. Peterson, “Feature-Oriented Domain Analysis (FODA) Feasibility Study”, CMU/SEI-90-TR-21 (1990)
• [14] K. C. Kang, V. Sugumaran, S. Park, “Applied Software Product Line Engineering”, Auerbach Publications (2010)
• [15] L. Gorchels, “The Product Manager's Handbook: The Complete Product Management Resource”, McGraw-Hill (2000)
• [16] 位野木万里, 杉本信秀, 深澤良彰, “ステークホルダの意思決定を支援するプロダクトライン再生シナリオの提案”, ソフトウェア工学の基礎ワークショップ(FOSE2008), pp.75–80 (2008)
• [17] 神谷年洋, 肥後芳樹, 吉田則裕, “コードクローン検出技術の展開”, コンピュータソフトウェア, Vol.28, No.3, pp.29–42 (2011)
• [18] J. Humble, D. Farley, “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation”, Addison-Wesley Professional (2010)
  (訳) 和智右桂, 高木正弘, “継続的デリバリー： 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化”, アスキー・メディアワークス (2013)
• [19] P. M. Duvall, S. Matyas, A. Glover, “Continuous Integration: Improving Software Quality and Reducing Risk”, Addison-Wesley Professional (2007)
  (訳) 大塚庸史, 丸山大輔, 岡本裕二, 亀村圭助, “継続的インテグレーション入門”, 日経BP社 (2009)
• [20] S. Thangthumachit, S. Hayashi, M. Saeki, “Understanding Source Code Differences by Separating Refactoring Effects”, Proc. APSEC'11, pp.339–347 (2011)
• [21] K. Herzig, A. Zeller, “The Impact of Tangled Code Changes”, Proc. MSR'13, pp. 121–130 (2013)
• [22] KDE TechBase, “Policies/Commit Policy”,
  http://techbase.kde.org/Policies/Commit_Policy#Commit_complete_changesets
• [23] S. Appleton, B. Berczuk, “Software Configuration Management Patterns”, Addison-Wesley (2002)
• [24] S. Person, M. B. Dwyer, S. Elbaum, C. S. Păsăreanu, “Differential Symbolic Execution”, Proc. FSE'08, pp.226–237 (2008)
• [25] S. Lahiri and C. Hawblitzel, “Symdiff: A Language-Agnostic Semantic Diff Tool for Imperative Programs”, Proc. CAV’12, pp.712–717 (2012)
• [26] D. Jackson and D. A. Ladd, “Semantic Diff: A Tool for Summarizing the Effects of Modifications”, Proc. ICSM’94, pp. 243–252 (1994)
• [27] 角田雅照, 門田暁人, 松本健一, 押野智樹, “受託開発ソフトウェアの保守における作業効率の要因”, コンピュータソフトウェア, Vol.29, No.3, pp.157–163 (2012)