情報処理学会論文誌

Vol.59 No.6 1405–1414 (June 2018)

AutoSort：レガシーシステム分析のためのプログラミング言語の判定支援手法
岡田 譲二1,2,a)

石尾 隆3,b)

坂田 祐司1,c)

井上 克郎2,d)

受付日 2017年7月10日, 採録日 2018年3月6日

概要：レガシーなメインフレームシステムには，拡張子が存在せずプログラミング言語が不明なソースコー
ドファイルが多数存在する．レガシーシステムを分析する際には各ソースコードファイルのプログラミン
グ言語を判定する必要があるが，これを手作業で行うと多大な労力が必要となってしまう．本研究ではプログラミング言語の判定作業を支援するために，手作業で判定すべきファイルの代表をクラスタリングによって選出する手法を提案する．正確な判定を支援するため，提案手法はパターンマッチによる自動判定と，手作業での判定結果を用いた解析による判定誤りの補正をクラスタリングに組み合わせて用いる．提案手法の評価として，人手で正解のプログラミング言語を付与した 2 つの実際のレガシーシステムのファイル集合に対して本手法を適用した．その結果，提案手法は 19 万ファイルのうち，99.49%のファイルを正しく分類できることを確認した．また，これらのファイルに対する人手での判定は 3.3 人月の工数が必要だったが，提案手法は 8 時間の計算時間と，人手による 15 分の確認だけで判定を完了した．
キーワード：レガシーマイグレーション，リバースエンジニアリング，プログラム理解，クラスタリング

AutoSort: A Supporting Method of Programming Language Detection
for Analyzing Legacy Systems
Joji Okada1,2,a)Takashi Ishio3,b)Yuji Sakata1,c)Katsuro Inoue2,d)Received: July 10, 2017, Accepted: March 6, 2018

Abstract: Legacy mainframe systems involve many source code files without file extensions. Their programming languages are undocumented. Therefore, their respective programming languages are not easily judged
by hand. Although detecting a programming language for each file is necessary for various program analysis
tasks, it is time consuming to manually analyze a large amount of files. In this research, we propose a method
to support the process of programming language detection employing a clustering technique to select a small
number of representatives for manual detection of programming languages. To improve accuracy, our method
combines pattern matching and a static analysis using a result of manual detection. In the experiment, weapplied our method to two actual legacy systems whose source code files have been manually analyzed. As aresult, our method correctly classified 99.49% of the 190,000 files. While a manual detection of programming
languages for the systems required 3.3 man-months, our method completed the analysis in eight hours forcomputation and fifteen minutes for manual checks of programming languages.
Keywords: legacy migration, reverse engineering, program comprehension, clustering

1
2
3

a)

株式会社 NTT データ技術革新統括本部
NTT DATA Corporation, Koto, Tokyo 176–0024, Japan
大阪大学大学院情報科学研究科
Osaka University, Suita, Osaka 565–0871, Japan
奈良先端科学技術大学院大学情報科学研究科
Nara Institute of Science and Technology, Ikoma, Nara 630–
0192, Japanokadaju@nttdata.co.jp

c 2018 Information Processing Society of Japan

1. はじめに
業務上は重要だが保守の継続が困難なメインフレーム上
b)
c)
d)

ishio@is.naist.jp
sakatayu@nttdata.co.jp
inoue@ist.osaka-u.ac.jp1405

情報処理学会論文誌

Vol.59 No.6 1405–1414 (June 2018)の基幹システム（以降はレガシーシステムと呼ぶ）がいま

プログラミング言語の判定においては，ファイル種別のだに多数存在している [1], [2]．レガシーシステムもビジネ

分類も必要である．ファイル種別とは，たとえば C 言語

ス変化に対応するためには保守し続けることが必要であにおけるソースファイルとヘッダファイル，COBOL におり，そのためにソフトウェア構造の可視化や，新しいプロ

けるメインファイルとコピーファイルというように，言語

グラミング言語や実行環境への移行といったシステム再構

としては同一であるが言語処理系にとっての役割が異なる

築のための活動が行われる [3], [4]．

ようなファイルの分類である．本研究では，構文解析の起

レガシーシステムの可視化や再構築の際には，現行シス点となるファイルをメインファイル，構文解析の起点とな

テムのソースコードを静的解析し，理解するというアプ

らないファイル（ヘッダファイル，コピーファイルなど）

ローチが用いられる [5]．静的解析手法の多くはソースコー

をインクルードファイルと呼んで区別する．インクルード

ドの構文解析を行っており，解析を行うための前提条件とファイルの多くは単独での構文解析が不可能であり，適切して，対象となるソースコードのプログラミング言語が何な解析を実行するには，これらのファイル種別まで含めたであるかをあらかじめ把握しておく必要がある．

プログラミング言語の判定を行うことが必要である．プロ

本論文では，レガシーシステムを構成するソースコード

グラミング言語に固有のキーワードなどに基づくパターン

ファイルに使用されているプログラミング言語を判定すマッチは，ある程度の自動的な判定は可能であるが，このる問題を取り扱う．一般的なソフトウェアシステムでは，

ようなファイル種別の判定には不十分である．

ソースコードファイルの拡張子やディレクトリ構造からプ

ソースコードファイルが与えられたとき，知識を持った

ログラミング言語を容易に判定することができるが，レガ

人間なら，そのファイルの内容からプログラミング言語をシーシステムではプログラミング言語の判定は容易ではな

推定することはそれほど難しくない．しかし，レガシーシ

い．最も大きな理由として，レガシーシステムでは拡張子

ステムではソースコードファイルが数万本あることは珍しやディレクトリが存在しないことがあげられる．メインフ

くなく，すべてのファイルのプログラミング言語を人手でレームは拡張子という概念が生まれる前から存在している判定するには多大な労力が必要である．第 1 著者が関わっため，ファイルに拡張子をつけるという文化がなく，実際たプロジェクトでは，プログラミング言語が不明なソースに多くのメインフレームのソースコードファイルには拡張

コードファイルが 17 万ファイル存在しており，そのうち 3子が付与されていない [6]．また，ディレクトリという概万ファイルは判定開始時に想定されていなかった未知のプ

念のないフラットなファイルシステムが使われており，プ

ログラミング言語のものであった．このファイル集合に対

ログラミング言語ごとにディレクトリを分けるようなファ

して，ファイル名の命名規約の活用や，ファイル内のキー

イル管理が行われておらず，システムを構成する複数の言ワードを grep で検索するといった方法で人手で判定を行っ

語のソースコードファイルやプログラムが利用するデータたところ，2 人で 1.5 カ月間の作業が必要であった．

ファイルが 1 つの場所に混在する状態となっている．

本論文では，大規模なレガシーシステムに大量に存在す

プログラミング言語判定の単純な自動化，たとえば既知る，プログラミング言語が分からないソースコードファイの複数の構文解析器を適用して成功したものを選ぶといっルについて，そのプログラミング言語とファイル種別を判た方式は，レガシーシステムに多様な言語が用いられるこ定する作業を支援する手法を提案する．提案手法のアイとと，プロジェクト独自の言語が含まれている可能性から

ディアは，クラスタリングによってファイルを分類し，ク

適用が困難である．長年の保守開発の中では，一時的な利ラスタの代表として選ばれたファイルだけに対して人間が用や性能上の問題解決という名目によって，たとえばスク

プログラミング言語の判定を行うというものである．人間

リプト系の言語やアセンブラなど，そのプロジェクトで主の労力を削減するために，パターンマッチによる判定が容に採用されている言語とは異なる言語も使われている場

易なプログラミング言語は事前に判定を行って人間の判定合が多い．これらの少数の言語は，保守開発者の入れ替わ

対象から除外する．また，人間が判定した結果に基づいてりによって存在すること自体さえも引き継がれることな構文解析を実行し，得られた情報を用いて誤りを補正する

く今に至ってしまい，現在の保守開発者にとって未知の言ことで，分類精度を向上させる．

語となっていることがしばしばある．また，規模の大きな評価実験として，2 つの実際のレガシーシステムのファプロジェクトでは，そのプロジェクト独自の拡張をプリプ

イル集合に対して提案手法を適用した．人手で判定した結ロセッサやコンパイラに施すことがある．新しいキーワー

果を正解として既存手法との正確性の比較を行うとともドを追加したり，文法を追加したりするといった独自の拡に，計算時間，作業時間の評価を行うことで，提案手法の張がなされたプログラミング言語は，一見すると元々の有効性を確認した．

COBOL だったり，PL/I に見えたりしても，通常の構文

以降，2 章では既存手法について紹介し，3 章で提案手

解析器ではまったく解析できないソースコードとなってい法について述べる．4 章で評価実験の方法と結果を説明し，ることがある．

5 章でまとめと今後の課題を述べる．

c 2018 Information Processing Society of Japan

1406

情報処理学会論文誌

Vol.59 No.6 1405–1414 (June 2018)

2. 既存手法

3. 提案手法：AutoSort

プログラミング言語の判定問題は，レガシーシステムに本研究では，人手によるプログラミング言語判定を効果固有の問題ではない．ドキュメントやメールなどに含まれ的に行う手法 AutoSort を提案する．提案手法はレガシー

るソースコード断片に使われているプログラミング言語のシステムのファイル集合を入力として，ファイル名や拡張

識別や，プログラミング言語間で共通の拡張子が用いられ子の情報を使うことなく，ファイルごとにプログラミングている場合への対応といった観点から，プログラミング言

言語とファイル種別のラベルを付与する．ファイル集合に語判定の研究が行われている [7]．具体的な判定手法としはプログラムの実行時に利用されるデータファイルやパラては，パターンマッチを利用した手法と，教師あり機械学

メータファイルも含まれており，これらは厳密にはプログ

習による判定手法が提案されている．

ラミング言語ではないが，プログラミング言語の一種と見Linguist [8] は，プログラミング言語ごとに構文の強調表示などを適切に行うことを目的とした，パターンマッチ

なしてラベルをつける．

AutoSort は図 1 に示すように 4 つのステップから構成を用いたプログラミング言語の判定ツールである．プログされる．

ラミング言語の中に含まれる特徴的なキーワードやパター( 1 ) パターンマッチによる事前分類

ンがあらかじめ列挙されており，それらのキーワードを含( 2 ) クラスタリング

む，もしくは決められたパターンにマッチするファイルを，( 3 ) 人手によるラベリング

当該のプログラミング言語として判定する．パターンマッ( 4 ) 意味解析情報による誤判定補正

チによる判定手法は，他の言語に比べて特徴が明確なプロ提案手法は，まず，パターンマッチによる事前の分類をグラミング言語に関しては有効なものの，頻出する単語を行う．このステップは，技術的には既存手法と同様である．

共通して持つプログラミング言語を判定する場合，適切な次に，Klein ら [9] の手法と類似した字句的な特徴を用いキーワードを作成することが難しい．また，キーワードやたクラスタリングを適用し，人手で判定するべき代表的なパターンを定義していない未知のプログラミング言語に対ファイルを選出する．そして，人手による判定を行ったのしては，判定ができない，あるいは誤って既知のプログラ

ち，その結果を用いて呼出関係などの解析を実行し，判定

ミング言語として誤判定してしまうという問題もある．

結果と解析結果の一貫性を確認することで誤判定の補正をパターンに頼らないプログラミング言語の判定手法と行う．各手法を段階的に組み合わせることで各手法の弱点

して，教師あり機械学習を用いた手法が提案されている．

を補い，高い精度と少ない工数，未知のプログラミング言

Klein ら [9] は，ソースファイルの各行に出現する単語や末語が含まれていたときのロバストネスの実現を目指して設尾に出現した文字，記号などの特徴を用いた機械学習を提計した手順となっている．

案している．van Dam ら [7] は，ソースコードを単語の列に分解し，n-gram などの機械学習モデルを適用した結果

3.1 ステップ 1：パターンマッチによる事前分類を報告している．これらの手法を適用するには，あらかじステップ 1 では，他のプログラミング言語に比べて特徴

めプログラミング言語が判定されているソースコードファが明確で判定が容易なものを，パターンマッチによる判定

イルを多数用意しておく必要があり，拡張子のある一般的を用いて分類する．特徴が明確で判定が容易なプログラミ

なプログラミング言語ではその準備が容易であるが，レガ

ング言語とは，以下のような特徴を持つプログラミング言

シーシステムでは教師データを準備することが困難であ語である．

る．また，プロジェクトごとに拡張された独自のプログラ
ミング言語などへの対応が困難である．

• 当該プログラミング言語で記述されたソースコードであれば，必ず記述する予約語や記法が存在する．

• その予約語や記法は当該プログラム特有であり，他の

図 1 AutoSort の手順

Fig. 1 Process of AutoSort.

c 2018 Information Processing Society of Japan


1407

情報処理学会論文誌

Vol.59 No.6 1405–1414 (June 2018)

表 1 プログラミング言語判定パターン

Table 1 Patterns of programing language detection.
プログラミング言語・ファイル種別

パターン

アセンブラ

1〜3 文字目がニーモニックキーワードである行数が全行数の 50%を超える

ADL

ダブルクォート内部以外で “ NAME IS” という文字列をファイル中に 1 つ以上含む

JCL メインファイル“ˆ//.+ +JOB” と “ˆ//.+ +EXEC” という文字列をファイル中にそれぞれ 1 つ以上含む

JCL インクルードファイル“ˆ//.+ +PROC” という文字列をファイル中に 1 つ以上含む，
もしくは “ˆ//.+ +JOB” という文字列をファイル中に 1 つ以上含むが，“ˆ//.+ +EXEC” という文字列は 1 つも含まない
Telon“TRANPORT MM/DD/YY HH:MM:SS” という文字列をファイル中に 1 つ以上含む

プログラミング言語では（めったに）記述されない．

このため本手法では．ソースコードの内容に起因する特

上記のような特徴を持つ言語どうしの判別であれば，パ徴量のみを選定することとし，名前や拡張子などを特徴量

ターンマッチによる判定の問題点が起こらない．パターンとして使用しない．

マッチで判定する言語を限定的にすることで，世の中に無レガシーシステムにおいては，アルファベットの大文字数に存在するプログラミング言語についての知識がなくとしか使えない，利用できる記号の種類が少ない，1 行あたりも適切なパターンを作成することができる．

の桁数が固定であるなど，端末の環境の制限が強く，プロ第 1 著者が所属する企業が保守開発する 4 つのレガ
シーシステムを予備調査した結果，アセンブラ，ADL（Aim Description Language），CA Easytrieve PLUS（以下 EASYPLUS と略す）[10]，JCL，Telon [11] が上記の特グラミング言語にもそれらの特徴が反映されているため，
これらの特徴に基づいた特徴量を選定することとした．
あるソースファイル f に対して使用する特徴量は以下のとおりである．

徴に当てはまると判断した．特に JCL については，構文• ファイルの行数（空行を含まない）

解析の起点となる JCL メインファイルと，メインファイ• 1 行あたりの平均文字数

ルから参照される JCL インクルードファイルという 2 つ• 空白を除く 1 ファイル内すべての文字に対する英字ののファイル種別に分類する判定パターンを定義した．それぞれのプログラミング言語を判定するパターンを表 1 に示す．表中の文字列はすべて正規表現である．
表 1 の記述順でパターンマッチを適用していき，マッ割合• 空白を除く 1 ファイル内すべての文字に対する数字の割合• 1 ファイル内すべての英字に対する大文字の割合

チしたファイルを当該のプログラミング言語として判定す• 括弧の 1 行あたりの平均出現数

る．マッチしなかったファイルを，ステップ 2，3 の判定• 特殊文字（ピリオドやカンマなど）の 1 行あたりの平処理の対象とする．

均出現数• 他のファイル名と同じ単語の出現数
3.2 ステップ 2：クラスタリング
ステップ 2 のクラスタリングでは，プログラミング言語• 様々な言語の予約語と考えられる単語（if や while など）230 種類それぞれについて，以下の 3 つの特徴量が持つ様々な特徴を用いて，ステップ 1 のパターンマッチ（合計 690 個）．

に該当しなかったファイルを k 個のクラスタに分類する．

– 1 文字目からその単語が出現する行の割合．

クラスタリングは，未知の言語や独自拡張された言語の– 各行の前半 1/3 でのその単語の平均出現数．

ソースコードファイルが含まれていても，それらが他のプ– 各行の後半 1/3 でのその単語の平均出現数．

ログラミング言語のファイルと書き方が類似していない限

これらの特徴量を選定した理由を表 2 に示す．

り，異なるクラスタとして認識することができる．なお，

ファイルからの単語の切り出しにおいては，空白，改行

ここでの k は手法のパラメータであり，システムに使われ文字，引用符およびピリオドを区切り文字として，それ以ているプログラミング言語の数よりも十分に大きい値を設

外の連続する文字列を単語として切り出している．プログ

定する．

ラミング言語ごとに引用符などの扱いのルールは異なるた

3.2.1 ファイルの距離

め，引用符で囲まれた範囲の内側，外側という区別は行わ本手法で想定しているファイル集合は，以下のようなものである．

ず，すべての区切り文字の出現を使用する．
特徴量は全部で 698 次元のベクトルと見なすことができ• 単一のディレクトリに存在しているるので，ファイル f1 , f2 の距離 d(f1 , f2 ) は，それらに対応• ファイル名は連番で命名されているする特徴ベクトル v(f1 ), v(f2 ) のコサイン類似度によって，• ファイル名に拡張子が付与されていない

以下のように定義する．

c 2018 Information Processing Society of Japan

1408

情報処理学会論文誌

Vol.59 No.6 1405–1414 (June 2018)

表 2 クラスタリングで用いる特徴量の選定理由

Table 2 Selection reasons of feature quantity used in clustering.
特徴量

選定理由

ファイルの行数

メインファイルは比較的長く，インクルードファイルは短いことが多い

1 行あたりの平均文字数

1 行あたりの文字数制限がある言語がある

英字の割合

コメントに英字しか記述できない言語と 2 byte 文字（日本語）を記述できる言語がある

数字の割合

データファイルは数字の割合が高い傾向がある

大文字の割合COBOL などの言語はすべて大文字で記述する傾向がある

括弧の平均出現数

ブロックを括弧で囲む言語と，括弧ではない予約語で囲む言語がある

特殊文字平均出現数

文の区切り文字が言語によって異なる

他のファイル名と同じ単語の出現数

他のファイルの呼び出しやインクルードなどを多数行う言語と，まったく行わない言語がある

出現位置ごとの予約語の平均出現数

予約語は必ず行頭に記述する言語と，どこに記述してもよい言語がある

d(f1 , f2 ) = 1 − cos(v(f1 ), v(f2 ))タとして指定する最大繰り返し数まで，1 と 2 を繰り返す．

3.2.2 K-means++ 法の適用

K-means 法は計算コストが小さいという利点があるが，ファイル集合に対して，非階層型クラスタリング手法の1 でランダムに選択するクラスタ中心の初期値によってク

1 つである K-means++ 法 [12] を適用する．非階層型クララスタリング結果が大きく異なってしまうという弱点があ

スタリングは，分割の良さを測る評価関数を定め，その評る．K-means 法よりも解析時間，クラスタリング精度の価関数を最適にするように分割する手法である．これに対両面で K-means++ 法の方が有効であるため，本手法ではして階層型クラスタリングは，要素数 1 の N 個のクラス

K-means++ 法を採用した．

タを初期状態として，最も距離が近い 2 つのクラスタを併合する作業を繰り返すことで階層的なクラスタ構造を得る

3.3 ステップ 3：人手によるラベリング手法である．非階層型クラスタリングは階層型クラスタリ

ステップ 3 では，ステップ 2 で k 個に分類された各クラングに比べて計算量が小さく，レガシーシステムで分析す

スタについて，1 つずつ代表となるファイルを人間に提示べきファイルは数十万を超えることがよくあることから，

し，人間がどのプログラミング言語なのかという判定を行本手法では実用的な解析時間で終わることを重視し，非階うことで，ラベリングを行う．

層型クラスタリング手法を選定した．

代表ファイルとして，本手法では各クラスタの中心に最K-means++ 法は，K-means 法 [13] の初期値設定を工夫も近いファイルを選択する．K-means 法は「各要素は群のしたアルゴリズムである．K-means 法では任意の k 個のク平均から離れていない」ことを保証する方法であるため，ラスタ中心を初期値として設定するが，K-means++ 法でクラスタに含まれるプログラムの「平均」に近いファイルは以下の手順でクラスタ中心の選択を行う．

を選ぶことで，出現する単語の数や種類の特徴を見落とし( 1 ) 1 つ目のクラスタ中心 c1 となるファイルを，解析対象
ファイル集合 F からランダムに選択する．

( 2 ) 各ファイル fj（j ∈ 1, 2, · · · , |F |）に対して，最も近い選
択済みのクラスタ中心との距離 D(fj ) = mini d(ci , fj )中心からクラスタに所属する各ファイルまでの距離を容易に計算することができる．
こうして選ばれた代表ファイルを人間に提示し，提示さを求める．
D(fj )2( 3 ) 確率分布 2f ∈F D(f )にくいと期待している．K-means++ 法では，各クラスタ
についてクラスタ中心が得られているため，そのクラスタを用いてランダムに次のクラス

れた人間はそのファイルに対してプログラミング言語を判

タ中心 cl となるファイルを選択する．つまり，どの定する．判定された代表的なファイルのプログラミング言

選択済みクラスタ中心からも離れているようなファイ

語を，そのクラスタに属するすべてのファイルのプログラ

ルを高い確率でクラスタ中心として選択する．

ミング言語としてラベリングする．つまり，このステップ( 4 ) クラスタ中心を k 個選ぶまで，2 から 3 を繰り返す．

が完了した時点で，すべてのファイルに対してプログラミ

クラスタ中心の選択以降は，K-means 法と同一で，以下の手順でクラスタリングを実行する．

ング言語のラベルが付与された状態となる．
ラベルとしてはプログラミング言語の名前を指定するだ( 1 ) 各ファイル fj（j ∈ {1, 2, · · · , |F |}）を，fj と最も近いけであるが，プログラミング言語によってはファイル種別

クラスタ中心 ci が所属するクラスタ Ci に割り当てる．

としてメインファイル，インクルードファイルの区別も同( 2 ) クラスタに属するファイルの特徴ベクトルの平均

ci = |C1i | f ∈Ci v(f ) を，新しいクラスタ中心とする．

時に指定する．また，データファイルに対しては，ファイ( 3 ) クラスタに変化がなくなるまで，あるいはパラメールであることを指定する．これらのファイル種別の指定

c 2018 Information Processing Society of Japan

ル形式の名称とは別に，ファイル種別としてデータファイ

1409

情報処理学会論文誌

Vol.59 No.6 1405–1414 (June 2018)

表 3 ファイル間の関係に基づく制約は，次のステップ 4 で使用する情報となる．

Table 3 Constraints based on relationship among files.

3.4 ステップ 4：意味解析情報による誤判定補正

ファイル間の関係

ファイルの種別に関する制約

ステップ 4 では，ステップ 3 までで判定したプログラミ

呼び出し関係

B は何らかのプログラミング言語のング言語が，既知の言語かつ，構文解析器や意味解析器を(A calls B)

メインファイルである．

インクルード関係

B はインクルードファイルである．

持っているプログラミング言語だった場合，そのプログラ
ミング言語と判定されたファイルに対して構文解析および意味解析を実行し，その結果を用いて誤判定の補正を行う．

(A includes B)

B の記述言語は A と同一である．

ファイル操作関係

B はデータファイルである．

(A reads/writes B)

このステップは必須ではなく，ステップ 3 で判定されたプ
ログラミング言語に対応する構文解析器や意味解析器をは必ず何らかの言語のメインファイルである（A と B

持っている場合のみ実施し，対応する構文解析器や意味解は異なる言語であることもありうる）．

析器を持っていない場合，単にこのステップを省略する．

– B が何らかの言語のインクルードファイルと判定さこのステップで補正が必要になる主な要因は，ステップ 2

れているのなら，メインファイルとインクルードファ

におけるクラスタリングにある．同じ言語のメインファイ

イルの種別判定を誤ったものと見なし，B の言語のルとインクルードファイルや，サイズが小さいファイルどメインファイルと判定する．

うしはそれぞれ特徴量の違いが少なく，異なる種類のファ– B がデータファイルの場合は，何らかの言語のメイ

イルが偶然同一のクラスタに分類されることがある．中身

ンファイルであるとして，人間に再度提示し，プロに何が含まれていても良いデータファイルについても，偶

グラミング言語の判定のやり直しを行わせる．

然ソースコードファイルに似ている場合がありうる．

• ファイル A が B をインクルードする場合，B を A と

このようなファイル種別の補正に，ソースコードの意味

同じ言語のインクルードファイルであると判定する．

解析から得られるファイル間の関係を利用する．対象のプ• ファイル A が B に対して何らかのファイル操作命令をログラミング言語の構文解析器や意味解析器を持ってい実行する場合，B をデータファイルであると判定する．

る必要があるが，意味解析を行うことでファイル内部に出

これらの補正ルールは，あるファイル B が他のファイル

現する他のファイル名の情報を取得し，ファイル間の関係から受ける操作に注目しており，通常はファイル B の種にともなう制約に基づいて，ファイル種別の正確な判定を別に応じて受付ける操作が異なることから，1 つのファイ行う．

ルに対しては 1 つのルールしか適用されない．1 つのファファイル間の関係情報として，呼び出し関係（A calls

イルに対して複数のルールが適用される場合は，参照元もB），インクルード関係（A includes B），ファイル操作関

しくは参照先のファイルの判別や意味解析が失敗している係（A reads/writes B）の 3 つを用いる．呼び出し関係とと考えられるため，参照元と参照先両方のファイルを人間

は，プログラミング言語の種類に関係なく別のソースコーに提示して，プログラミング言語の判定のやり直しを行わ

ドファイルを呼び出す命令による関係である．COBOL のせる．

CALL 文や JCL の EXEC PGM 文などが該当する．イン

このステップが完了すると，提案手法の出力として，プ

クルード関係とは，ヘッダファイル，コピーファイルのよログラミング言語・ファイル種別によってラベル付けされうなインクルードファイルを埋め込む命令による関係であたファイルの一覧が得られる．

る．COBOL の COPY 文や JCL の INCLUDE 文などが該当する．ファイル操作関係とは，ファイルの入出力を行う命令である．COBOL の READ 文や WRITE 文が該当する．

4. 評価実験
実際のレガシーシステムのファイル集合 2 つに対して，提案手法である AutoSort と既存手法との比較実験を行っ

これらの関係はファイルの構文解析および意味解析にた．評価の観点は，提案手法の正確性と，適用に必要な工

よってファイル名の出現位置を調べることによって得ら数および解析時間である．そのために，すべてのファイルれるもので，表 3 に示すように，呼び出し，インクルーに対して従来のやり方であるファイル内のキーワード検索

ド，ファイル操作の対象となるファイルは，それぞれメイなどに頼った人手でのプログラミング言語の判定を行い，ンファイル，A と同じプログラミング言語のインクルード

それを正解とした．実行時間の評価の基準となる人手の判ファイル，データファイルに限られるという制約が存在す

別工数は，このときの作業時間を計測したものである．

る．ステップ 3 までの判定結果がこれらの制約を満たして正確性の評価指標としては，クラス分類器の評価で広くいない場合，判定結果が誤っていると考えられるため，こ採用されている適合率，再現率を用いる．あるプログラミ

れらを用いて，以下のルールに従って補正を実行する．

ング言語 l について，• ファイル A から B への呼び出しが存在する場合，B
c 2018 Information Processing Society of Japan• l が正解であるファイルを l と判別した数を T P (l)1410情報処理学会論文誌

表 4

Vol.59 No.6 1405–1414 (June 2018)

実験に用いたファイル集合

FORTRAN，SQL，DATA の 9 個である．なお，システ

Table 4 File sets used for experiment.
システム名
総ファイル数言語の一覧

ム A の Format はこのプロジェクト独自の DSL であり，システム A

システム B

18,399174,735

アセンブラ

アセンブラ

EASYPLUS

EASYPLUSDATA はプログラムの実行時に利用されるデータファイル
やパラメータファイルのことである．
提案手法の効果を評価するために，各ファイル集合に対して，以下の 3 つの手法を適用した．

COBOL

COBOL

CICS MAP

JCL

FormatPL/I

タは，クラスタ数 k を 40，繰り返し数を 10 とした．

FORTRANADL

この k の値は，過去の経験から，多くのシステムで用AutoSort 提案手法．クラスタリングにおけるパラメー

SQL

DATA

いられるプログラミング言語を上回ることが想定され

DATA

Telon

る値である．

8

8

アセンブラ

アセンブラ

EASYPLUS

EASYPLUS

COBOL MAIN

COBOL MAIN

あらかじめ言語の特徴を教師あり機械学習する必要が

COBOL INC

COBOL INCあるため，K = 10 で K-分割交差検証を行い，10 回

CICS MAP

JCL MAINの検証結果の平均を評価した．このとき，ファイル集
合は判別するクラスごとに 10 個ずつに分割しており，言語の総数判別するクラスの一覧

Simon-Weber 機械学習によって言語判定を行う Kleinらの手法 [9] に対応する実装 [14] である．この手法はFormatJCL INC

FORTRAN

PL/I MAIN

ファイルの割合は維持したものとなっている．

SQL

PL/I INC

DATA

ADL

Clustering 提案手法のクラスタリングのみ，すなわちDATA

ステップ 2 と 3 のみを単純に適用したもの．特徴量，

Telon

距離，クラスタリングのパラメータは提案手法と同一判別するクラス数

911

人手による判別工数

56

485(人・時間)

である．

AutoSort のステップ 4 で利用する構文解析器・意味解析器としては，JCL，COBOL，PL/I のみを持っているとして，これらの構文解析器・意味解析器を用いる．

• l が正解以外のファイルを l 以外と判別した数を T N (l)AutoSort と Simon-Weber の比較によって既存手法との• l が正解であるファイルを l 以外と判別した数を F N (l)違いを調査し，また，AutoSort と Clustering の比較によっ• l が正解以外のファイルを l と判別した数を F P (l)て本研究で導入しているパターンマッチや誤判定の補正のT P (l)T P (l)とすると，適合率は T P (l)+F P (l) ，再現率は T P (l)+F N (l) で効果を調査する．

表される．また，あるシステム x 全体のプログラミング言

AutoSort および Clustering の処理は Python を用いて語種別の集合を L(x) とし，システム全体のファイル総数

実装した．実行時間の計測環境は，CPU として Intel Xeon

を F ile(x) とするとき，

E7-2860 2.27 GHz を搭載し，256 GB RAM，15,000 rpm

l∈L(x) T P (l)F ile(x)をシステム x の全体

正解率と呼ぶこととする．

HDD を記憶領域として備えた計算機である．

実行時間の評価としては，クラスタリングにおける人手でのラベリングの工数と解析時間を指標として用いる．

4.2 実験結果
4.2.1 正確性の評価

4.1 実験方法

正確性の比較実験結果を表 5 と表 6 に示す．提案手法

実験に用いたファイル集合は，第 1 著者が所属する企業はほとんどのプログラミング言語・ファイル種別で適合率，

で実際に保守開発を行っているやや小規模なレガシーシス

再現率が 95%以上となった．また，全体正解率は両システ

テムと，大規模なレガシーシステムの 2 つである．2 つのムで 99%以上，合計で 99.49%となっており，従来手法やファイル集合の概要を表 4 に示す．

単純なクラスタリングの適用に比べて適合率，再現率はい判別するクラスとは，言語とファイル種別を足しあわせて重複を省いたものである．言語にメインファイルとイン

ずれも大きく向上していることが分かる．
提案手法の各ステップ完了時点での適合率の値を表 7

クルードファイルの種別があるものについては，表中でに，再現率の値を表 8 に示す．これらの表は紙面の都合上は言語名の後ろにそれぞれ MAIN，INC と表記した．たシステム B についての結果のみを示すが，ステップ 3 まで

とえばシステム A でいうと，アセンブラ，EASYPLUS，である程度高い適合率，再現率を達成していることが分か

COBOL メインファイル（COBOL MAIN），COBOL イン

る．仮にステップ 4 で用いた JCL，COBOL，PL/I の構文

クルードファイル（COBOL INC）
，CICS MAP，Format，解析器を持っていなかった場合は，このステップ 3 までの

c 2018 Information Processing Society of Japan


1411

情報処理学会論文誌

Vol.59 No.6 1405–1414 (June 2018)

表 5 正確性の比較実験結果：システム A

Table 5 Comparative experiment result on accuracy: System A.
AutoSort
判別するクラス

Correct

Simon-Weber

Clustering

適合率 (%)

再現率 (%)

適合率 (%)

再現率 (%)

適合率 (%)

再現率 (%)

アセンブラ

204

96.52

95.10

69.66

79.90

100.0045.59

EASYPLUS

337

100.00

98.81

30.66

87.24

14.46

10.68

8,858

99.92

100.00

92.31

27.51

99.95

97.53

COBOL INC

5,891

100.00100.00

44.26

74.20

98.15

92.65

CICS MAP

2,769

100.00

99.53

85.66

97.91

99.70

96.86

COBOL MAIN

Format

198

85.53

98.48

63.52

74.75

97.93

95.45

FORTRAN18

100.00100.00

1.86

72.22

77.78

77.78

SQL

23

100.00100.00

37.93

95.65

100.00

95.65

DATA

101

92.86

77.23

15.12

79.21

10.75

99.71

全体正解率
表 6

99.01

55.65

93.66

正確性の比較実験結果：システム B

Table 6 Comparative experiment result on accuracy: System B.
AutoSort

Simon-Weber

Clustering

Correct

適合率 (%)

再現率 (%)

適合率 (%)

再現率 (%)

適合率 (%)

再現率 (%)

3,704

100.00100.00

0.00

0.00

98.43

96.44

アセンブラ

277

98.58

100.00

4.04

16.25

0.00

0.00

EASYPLUS

292

99.65

98.29

2.57

34.59

0.00

0.00

COBOL MAIN

20,960100.00

99.99

60.54

9.95

100.00100.00COBOL INC

19,43599.83

100.00

37.90

57.93

97.03

97.39

JCL MAIN

3,187

100.00

99.34

8.51

50.89

41.17

54.47

JCL INC

21,06299.75

100.00

61.55

67.51

93.00

85.81

PL/I MAIN

22,312

99.38

98.24

58.34

63.83

96.69

93.96

PL/I INC

93.74

判別するクラスADL

52,307

99.76

99.76

74.01

53.35

97.18

Telon

463

100.00100.00

11.77

67.17

0.00

0.00

DATA

30,736

99.87

98.78

69.86

67.36

86.59

98.18

99.47

全体正解率

表 7

52.93

表 8

各ステップでの適合率：システム B

Table 7 Precision at each step: System B.

93.54

各ステップでの再現率：システム B

Table 8 Recall at each step: System B.

1

2,3

4

1

2, 3

4

ADL

100.00100.00100.00ADL

100.00100.00100.00

アセンブラ

98.58

98.58

98.58

アセンブラ

100.00100.00100.00EASYPLUS

99.65

99.65

99.65

EASYPLUS

98.29

98.29

98.29

COBOL MAIN

0.00

100.00100.00COBOL MAIN

0.00

99.99

99.99

COBOL INC

0.00

99.82

99.83

COBOL INC

0.00

95.12

100.00JCL MAIN

100.00100.00100.00JCL MAIN

99.34

99.34

99.34

JCL INC

99.75

99.75

99.75

JCL INC

100.00100.00100.00PL/I MAIN

0.00

85.45

99.38

PL/I MAIN

0.00

98.24

98.24

ステップ

ステップ

0.00

98.66

98.76

PL/I INC

0.00

92.32

99.76

Telon

100.00100.00100.00Telon

100.00100.00100.00

DATA

0.00

95.93

99.87

DATA

0.00

98.78

98.78

PL/I INC

適合率，再現率となる．

ステップ 3 までの結果を基に，ファイル数が多そうなプロ提案手法のステップ 4 によって，クラスタリングの際にグラミング言語から優先的に構文解析器を用意すると効率誤判定されたインクルードファイルが正しい分類に再分類

良く判定精度を向上させることができると考えられる．

されている．ステップ 4 は工数をかけて構文解析器を多種

適合率，再現率の高さは，第 1 著者が所属する企業で類用意できれば，より判定精度が上がることが予想される．

は十分に実用的であると判断された．適合率，再現率がc 2018 Information Processing Society of Japan


1412

情報処理学会論文誌

表 9Vol.59 No.6 1405–1414 (June 2018)

工数および解析時間の比較結果：システム A

あるため，レガシーシステムのプログラミング言語であれTable 9 Comparative experiment result on utility: System A.

ば精度良く分類ができると考えている．

手法

AutoSort

S.-Weber

Clustering

人手

一方で，レガシーシステム以外でよく用いられるプログ

人手時間

7 m 41 s

0 m 00 s

7 m 37 s

6 人日

ラミング言語（C 言語や Java など）に関しては，本手法

解析時間46 m 49 s

11 m 42 s

21 m 03 s-で提案した特徴量以外に，新しい特徴量を導入する必要があるかもしれない．しかし，クラスタリングによって代表

表 10 工数および解析時間の比較結果：システム B

ファイルを選出するというアイディア自体はレガシーシス

Table 10 Comparative experiment result on utility:

テムに固有というわけではないため，文書中に埋め込まれSystem B.
手法

AutoSort

S.-Weber

Clustering

人手

人手時間

7 m 00 s

0 m 00 s

7 m 12 s

3 人月

解析時間

7 h 10 m 40 s

2 h 32 m 14 s

3 h 16 m 48 s-

たソースコード断片などのプログラミング言語判定に応用することも考えられる．
プログラミング言語によっては，複数のバージョン，派
生言語，方言などが存在する．そのようなプログラミング

100%にならないことを前提とした本手法の利用プロセス

言語が複数使用されているようなシステムを対象として，の確立が議論され，レガシーシステムの分析サービスを受それらの違いを判定しなければいけない場合，ファイル間ける顧客への事前説明を行ったうえで現場が利用するツーでの特徴量の差異が小さくなり，分類精度が低下すると考ルの 1 つとして採用された．

えられる．

ただし，基幹システムの移行作業においては，システムの機能を見落とすことが多大な影響を及ぼす可能性があり，

5. おわりに

再現率について 100%を求められる場合も存在する．この

本論文では，レガシーシステム内に雑多に混在する複数

ような場合には人間がすべてのファイルを目視する作業をのプログラミング言語で記述されたファイル集合から，そなくすことができない．しかしその場合であっても，提案

れらのプログラミング言語およびファイル種別を判定する手法によってソースファイルにラベル付けされていれば，

手法 AutoSort を提案した．提案手法は，クラスタリング

作業者はほとんどのソースファイルのラベルを確認する作によって特徴が類似するファイルをまとめ，そこから人間業だけで済むため，一定の作業時間短縮の効果はあるものが判定すべき代表ファイルを選出することで，効果的な判と思われる．判定結果として複数のプログラミング言語を定を可能とした．また，作業者の労力を減らすために，パ候補として出力するなど，再現率を 100%とするような拡

ターンマッチによる一部の言語の分類と，事後的な解析に張を行うことが今後の課題である．

よる誤判定の補正を組み込んだ．

4.2.2 適用に必要な工数および解析時間の評価

提案手法と既存手法との比較実験では，クラスタリング

提案手法の実行および人手での分析に要する工数の比較

が機械学習手法よりも正確な結果となること，また，パ

実験結果を表 9 と表 10 に示す．人手による分析作業の場

ターンマッチおよび誤判定の補正が提案手法の正確さに貢合，1 ファイルあたりの作業時間は平均で 10 秒程度である

献していることを確認した．適用する場合の作業工数も十が，ファイル数に比例した工数が必要であった．提案手法

分に現実的なものであり，現場で使用するツールとして受ではファイル数とは関係なく，クラスタ数に比例する工数

け入れられた．

で実施できる．提案手法における分析でも 1 ファイルあた

今後の課題としては，再現率について 100%を求められり 10 秒程度という工数は変わらず，k = 40 とした本実験るような状況に対応するための再現率を重視した提案手法

ではシステム A，システム B ともに約 7 分であった．全自の拡張があげられる．また，クラスタリングによって代表動で動作する機械学習手法に比べると作業時間は必要であファイルを選出するというアイディア自体はレガシーシス

るが，十分に実用的として現場でも受け入れられた．

テムに固有というわけではないため，文書中に埋め込まれなお今回の実験では，手作業での実験開始時に分析者にとって未知の言語であったもの（Format，FORTRAN）がたソースコード断片などのプログラミング言語判定に応用することも考えられる．

含まれていたため，実作業時にはこの言語が何であるかを謝辞 今野有一氏，NTT データ数理システム阿部裕介

有識者に数時間インタビュしているが，本実験の工数にこ氏には本研究についてアドバイスを賜った．またニューソの時間は含めていない．この工数はどの手法を採用するにン株式会社永田宏樹氏には実験にご協力していただいた．

しても必要な工数であり，ファイル数とは関係なく一定のここに謝意を表する．

工数が必要であると考える．

4.2.3 本手法の適用範囲
本手法で選定した特徴量は，レガシーシステムの端末環境に由来するプログラミング言語の特徴を反映したもので

c 2018 Information Processing Society of Japan


参考文献
[1]

Bennett, K.: Legacy systems: Coping with success,IEEE Software, Vol.12, No.1, pp.19–23 (1995).

1413

情報処理学会論文誌

[2]

[3]

[4]

[5]

[6]

[7]

[8]
[9]

[10]
[11]
[12]

[13]

[14]

Vol.59 No.6 1405–1414 (June 2018)

Khadka, R., Batlajery, B.V., Saeidi, A.M., Jansen, S.
and Hage, J.: How do professionals perceive legacy systems and software modernization?, Proc. 36th International Conference on Software Engineering, pp.36–47(2014).
Bisbal, J., Lawless, D., Wu, B. and Grimson, J.: Legacy
information systems: Issues and directions, IEEE Software, Vol.16, No.5, pp.103–111 (1999).
Ganesan, A.S. and Chithralekha, T.: A Survey on Survey of Migration of Legacy Systems, Proc. International
Conference on Informatics and Analytics, pp.72:1–
72:10 (2016).
Bisbal, J., Lawless, D., Wu, B., Grimson, J., Wade, V.,
Richardson, R., O’ Sullivan, D.: A survey of research
into legacy system migration, Technical Report, Trinity
College Dublin (1997).
神居俊哉，高尾 司：メインフレーム実践ハンドブッ
ク：z/OS (MVS), MSP, VOS3 のしくみと使い方，リックテレコム (2009).
van Dam, J.K. and Zaytsev, V.: Software Language
Identification with Natural Language Classifiers, Proc.
23rd International Conference on Software Analysis,
Evolution, and Reengineering, pp.624–628 (2016).
Github: Linguist, available from https://github.com/
github/linguist.
Klein, D., Murray, K. and Weber, S.: Algorithmic Programming Language Identification, CoRR,
Vol.abs/1106.4064 (2011) (online), available fromhttp://arxiv.org/abs/1106.4064.
CA Technologies: CA Easytrieve PLUS, available fromhttp://www.ca.com/jp/devcenter/ca-easytrieve.aspx.
CA Technologies: CA Telon, available from http://
www.ca.com/us/products/detail/ca-telon.aspx.
Arthur, D. and Vassilvitskii, S.: K-means++: The
Advantages of Careful Seeding, Proc. 18th ACMSIAM Symposium on Discrete Algorithms, pp.1027–
1035 (2007).
MacQueen, J.: Some methods for classification and analysis of multivariate observations, Proc. 5th Berkeley
Symposium on Mathematical Statistics and Probability,
pp.281–297 (1967).
Weber, S.: Programming-Language-Identification, available from https://github.com/simon-weber/
Programming-Language-Identification.

石尾 隆 （正会員）
2003 年大阪大学大学院基礎工学研究科博士前期課程修了．2006 年同大学
大学院情報科学研究科博士後期課程修了．同年日本学術振興会特別研究員．2007 年大阪大学大学院情報科（PD）
学研究科助教．2017 年奈良先端科学
技術大学院大学情報科学研究科准教授．博士（情報科学）．
プログラム解析，プログラム理解に関する研究に従事．

坂田 祐司 （正会員）
1996 年東京大学大学院工学系研究科材料学科博士前期課程修了．同年 NTT
データ通信株式会社（現，株式会社

NTT データ）入社．プログラム解析，
システムモダナイゼーションに関する研究に従事．

井上 克郎 （正会員）
1979 年大阪大学基礎工学部情報工学科卒業．1984 年同大学大学院博士課程修了．同年同大学基礎工学部助手．

1984〜1986 年ハワイ大学マノア校情報工学科助教授．1989 年大阪大学基礎工学部講師．1991 年同助教授．1995
年同教授．2002 年大阪大学大学院情報科学研究科教授．工学博士．ソフトウェア工学，特に，ソフトウェア開発手法，
プログラム解析，再利用技術の研究に従事．本会フェロー．

岡田 譲二 （正会員）
2006 年名古屋大学工学部電気電子情報工学科卒業．2008 年同大学大学院博士前期課程修了．同年株式会社 NTT
データ入社．プログラム解析技術の研究開発および現場適用に従事．

c 2018 Information Processing Society of Japan

1414