  |
  |
2009年11月22日     |
|
事業仕分けによる次世代スーパーコンピューターの開発予算削減について、どうお考えですか?
  |
ソフトウェア品質・生産性を向上させるコードクローン技術 国内internet.com発の記事
■ システム保守のリスク
今年12月に起きた証券会社による新規上場株の大量誤発注問題は、証券会社担当者の人為的なミスと東証のシステムの不具合が重なったことによって発生した。この問題は経営責任を問われる事態に波及し、東京証券取引所の代表取締役をはじめ3名の役員が辞職したことは記憶に新しい。 今やシステムの不具合ひとつで、社長の首が飛ぶ時代になったといえる。こういった状況下において、長年保守を行っているシステムの品質が満足いく状態であると胸を張って言えるシステム担当者は何人いるだろうか。このようなシステムを分析し、危険性を定量的に示す研究のひとつがコードクローン技術である。 ■ コードクローン技術 コードクローンとは、ソースコードの一部を複製することで作られたコードの部分である。プログラマは、新たな機能を実装するために既存のコードを複製し一部を変更する。しかし、オリジナルのコードとほぼ同一か非常に似ている。当然、似た機能を持つコードは一箇所だけでよいわけで、こういったコードのクローンが多く存在すると、保守性や品質が悪いシステムになる可能性が高い。 ■ コードクローンの量 一般的にコードクローンは5-10％くらいはあると言われている。最近の研究によると、Linux Kernel（2002年）のコードクローンは15-20％、Gnu Compiler Collection（1999年）は9％、X Window system（1995年）は19％、Sun Java SDK（2002年）は21-29％と言われている。有名な OSS システムでもこれほどのコードクローンを含んでいる。一般のインハウスのアプリケーションシステムではさらに多いとだろう。ある Cobol で書かれた給与システムは60％がコードクローンであったとの報告もある。 ■ コードクローンの原因 コードクローンが発生する原因はなんであろうか。コーディングを行う上で、既存のコードと似たコードを書きたいことはよくある。そのコードをコピーして、すこし修正すれば簡単に新しい機能をコーディングすることができる。よく考えれば、既存のコードを修正し、新しい機能を満たすように実装すればよい。しかし、テストが完了して稼動している既存のシステムの一部を変更するのはリスクが伴う。必要な部分をそのままコピーして、新しいモジュールの一部にしてしまえば、既存のモジュールへの影響はない。 こういった考えから、コードクローンが発生してしまうのだろう。特に初期開発から10年以上も保守し続けて、開発担当者も引き継ぎ引継ぎを繰り返し、既存のコードを変更するリスクをとりたくないときにはこういった方法で新規開発を行わざるを得ない。共通した部品として切り出すべき機能であったとしても、複数のモジュールから利用されるとしたら、修正ミスが関連する複数のモジュールに波及してしまうことを防ぎたいという気持ちもある。モジュール強度を高めたいとの気持ちとも結びつくだろう。 しかしながら、不具合の修正があるコードクローンに対して行われた場合、すべてのクローンも修正しないと危険であることも事実である。コードクローンは、リファクタリングを行うことを困難にして、保守性を低下させてしまう原因になる。 ■ コードクローン研究の経緯 コードクローンの研究は、1990年代の中ごろから主に海外で行われてきていた。Baker による研究では、ソースコードを行単位で比較してコードクローンを検出しようと試みた。BaxterはC言語のソースコードを構文解析して解析木を比較することによってコードクローンを発見する方法を発表した。さらに Baxter は発見したクローンを、インラインプロシージャやプリプロセッサを使用して自動的に削除する方法についても言及している。 ■ CCFinderX 日本では、大阪大学大学院情報科学研究科の井上研究室において、コードクローンの研究が進められている。井上研究室でコードクローンの研究を行っていた現産業技術総合研究所の神谷年洋氏は、コードクローンを効率よく発見するツール CCFinderX を開発した。CCFinderX は、ソースコードを字句解析してトークンの列に直してからコードクローン検出を行うツールである。 ソースコードを言語の文法知識に基づき変形し解析するには、�．�ラススコープや名前空間による複雑な名前の正規化を行う�⊇藉�化テーブルを取り除く��モジュールの区切りを認識するというステップで行う。Baxter の研究に比べて、ほぼ字句解析しか行わないため、発見の精度が低下する可能性もあるが、新しい言語へ迅速な対応が可能となる。また、非常に高速処理な処理が実現できるため大規模なシステムに適用可能である。 近年、CCFinderX をより簡単に利用できるための GUI フロントエンド GemX 等も開発されており、ユーザーインターフェースが改善されている。 ■ CCFinderX の試行 日本ユニシスが OSS で公開している Rinza RDF Repository のソースコードを CCFinderX と GemX を使用して分析してみた。 CCFinderX Version: 10.0.9 Web site: http://www.ccfinder.net/ccfinderx-j.html 最小クローン長 100 最小クローンセットサイズ 10 ファイル数は632ファイルである。
散布図は、縦軸と横軸にソースファイル名を並べてあり、黒い点が発見されたコードクローンである。つまり対角線にある黒い点は同一のファイル内にコードクローンが発生していることを示す。Rinza RDF Repository は、2004年に開発されたシステムであるため、比較的コードクローンは多くない。下のほうに集中しているコードクローンはコード生成ツールによって生成されたコードである。 ■ 終わりに ソースコードの中身を開発の側面から定量的に分析するツールは数多くある。エディタの文法解析機能や静的解析ツールは、開発者を補助する観点から用意されたツールである。しかしながら、ソースコードの品質を捉えるには、十分であるとは言えないものが多いと思う。コードクローン技術によって、既存の大規模なシステムを静的に解析し、システムの保守性を定量的に示すことが可能である。 システムのコードクローンの量の経年変化を捉えることも保守性との関係を導くために有効であろう。また、外部委託した開発を評価するためにも利用できる可能性がある。 参考文献 B.S. Baker, “On finding Duplication and Near-Duplication in Large Software System”, Proc. Second IEEE Working Conf. on Reverse Eng., pp. 86-95 Jul. 1995. I.D. Baxter, A. Yahin, L. Moura, M. Sant’Anna, and L. Bier, “Clone Detection Using Abstract Syntax Trees”, Proc. IEEE Int’l Conf. on Software Maintenance（ICSM）’98, pp. 368-377, Bethesda, Maryland, Nov. 1998. Toshihiro Kamiya, Shinji Kusumoto, and Katsuro Inoue, “CCFinder: A Multi-Linguistic Token-based Code Clone Detection System for Large Scale Source Code,” IEEE Trans. Software Engineering, vol. 28, no. 7, pp. 654-670, （2002-7）. Michael Toomim, Andrew Begel, Susan L. Graham Department of Computer Science University of California at Berkeley “Managing Duplicated Code with Linked Editing” 2004 提供:日本ユニシス |
japan.internet.com 10周年記念
インターネットコムマーケティングセミナー ROI を最適化するパフォーマンスマーケティングの最前線 【12/16(水)13時〜 東京・赤坂】 申込はコチラ>> 
|
営業
日本ユニシス 江平裕昭
