ソフトウェアエンジニアリングシンポジウム 2016
IPSJ/SIGSE Software Engineering Symposium (SES2016)

バッチ処理システムにおけるデータセット間の依存関係の抽出竹之内 啓太1,a)

石尾 隆1,b)

岡田 譲二2,1,c)

坂田 祐司2,d)

井上 克郎1,e)

概要：バッチ処理とは計算機システムに蓄積されたデータを一定期間ごとに一括で計算する処理の方式である．レガシーシステムには数多くのバッチ処理が含まれているが，いずれも 1 つ以上の入力データセッ
ト（データの系列）から 1 つ以上の出力データセットを作成する処理とみなすことができる．本研究では，バッチ処理システムが実行する個別のバッチ処理の概要として，各出力データセットが依存する入力データ
セットの集合を抽出する手法を実現した．具体的には，ジョブ制御言語で記述されたバッチ処理の上でのデータ依存関係解析に加え，バッチ処理の各ステップに対応する COBOL プログラム内部のデータ依存関係を解析することで，より詳細なデータ依存関係の解析を可能とした．ケーススタディとして，あるレガシーシステムのバッチ処理の分析に適用したところ，手法のデータ依存関係解析は多くのバッチに対し有効であり，COBOL プログラムの内部を考慮した詳細化が有効であるバッチが存在することが確認できた．

Extraction of Dependence Relation among Data-sets
in Batch Processing System
Keita Takenouhi1,a)Takashi Ishio1,b)Joji Okada2,1,c)Yuji Sakata2,d)Katsuro Inoue1,e)Abstract: Batch processing is a data processing mode which runs at regular intervals and treats a series ofaccumulated data. Legacy systems are mainly composed of batch processes and a batch process generates
output data-sets using input data-sets. In this paper, we propose a method to extract output data-sets
and their corresponding input data-sets as a summary of a batch process. This approach performs data
dependence analysis for not only job control language but also COBOL programs to realize a more detailed
analysis. A case study with a real legacy batch system shows that data dependence analysis on data-sets is
eﬀective in many batch processes and that the detailed analysis on COBOL is eﬀective for a particular setof batch processes.

1. はじめにバッチ処理システムとは，一定期間ごとに大量のデータを一括に計算するバッチ処理を実行するためのシステムである．企業活動を支えるソフトウェアシステムの中でも，業務における売り上げの集計や給与の計算といった基幹業
務を果たすものであり，その多くは数十年前に開発されてから現在まで保守され続け，社会的に大きな役割を担っている [1], [2]．
バッチ処理システムは，レガシーシステムと呼ばれているものの 1 つである．メインフレームコンピュータ上で

1

2

a)
b)
c)
d)
e)

大阪大学大学院情報科学研究科
Graduate School of Information Science and Technology, Osaka University
株式会社 NTT データ
NTT DATA Corporation
t-keita@ist.osaka-u.ac.jp
ishio@ist.osaka-u.ac.jp
okadaju@nttdata.co.jp
sakatayu@nttdata.co.jp
inoue@ist.osaka-u.ac.jp©2016 Information Processing Society of Japan

稼働しており，システムとして社会的に大きな役割を担う
一方で，長年の保守開発によりシステムの大規模化や複雑化が進んでいる傾向がある．さらに，ドキュメントが消失していることによりシステムの仕様が不明確であったり，

COBOL やメインフレームコンピュータ等の古くなった技術に精通している技術者が現場から離れている問題もあり，

14ソフトウェアエンジニアリングシンポジウム 2016
IPSJ/SIGSE Software Engineering Symposium (SES2016)

結果として運用・保守に必要な費用が増加している [3]．

タ依存関係グラフを構築することによるデータセットの依

レガシーシステムを最新の技術を用いたシステムへと作存関係の解析が多くの場合で有効であることや，COBOL

り替えることで，さらに継続的な運用，保守を可能とするプログラムのスライシングによる解析の詳細化が有効であ

取り組みがレガシーモダナイゼーションである．過去になる場合が存在することを確認した．また，手法の出力となされてきたレガシーモダナイゼーションの研究としては，

るデータセットが具体的にどのくらいの規模になるのかをプログラムの自動変換，すなわち古いプログラミング言語

調査し，動作の概要を理解するために重要でないと考えらで記述されたソースコードを比較的新しいプログラミングれるデータセットを除外するという，手法での工夫点が有言語のソースコードに自動的に変換する取り組み [4], [5]

効に働くときがあることを確認した．

が挙げられる．しかしながら，プログラミング言語の自動以降，2 章では関連研究について述べ，3 章で提案手法

変換は言語レベルでのモダナイゼーションを行うものでを説明する．4 章でケーススタディについて，5 章は妥当あり，システムの設計そのものを作り直すことにはならな性への脅威についてそれぞれ述べる．6 章でまとめと今後

い．そのため，元のレガシーシステムの設計やデータ構造の課題を述べる．

の悪い部分も新システムに引き継がれることになり，結果としてモダナイゼーションのレビューやテストの工程にお2. 関連研究いて，新システムにおける保守性の問題や実行速度などのHasselbring ら [6] は，レガシーシステムから多層アーキ

パフォーマンス面での問題が生じることがある．これがシテクチャをもつ新システムへの移行の手法として Dublo パ

ステム設計の見直しなど開発工程の後戻りを引き起こし，ターンを提案している．この手法は既存のレガシーシステ

新システムのリリースまでに膨大なコストがかかる原因のムのコードをそのまま活用するため，新たなユーザイン

1 つとなっている．

ターフェースと，ビジネスロジックを追加するための中間

我々の研究グループは，レガシーシステムの動作をその層を作成し，それらから間接的にレガシーシステムに接続

まま新システムへと反映するのではなく，レガシーシステするというものである．既存のコードやデータベース設計

ムから一度システムの動作の概要を抽出し，得られた情報などをそのまま再利用できるということや，徐々に新シスに基づいてシステムの設計そのものを見直すことでレガテムへ機能を移行できるという利点を持つ一方で，機能にシーモダナイゼーションを達成することを目指している．

対応するコード片を事前にレガシーシステムから識別する

たとえば，COBOL プログラムの多くは業務データの集計必要がある．

処理を担当しているため，使用しているデータの入出力のPrez-Castillo ら [7] は，レガシーシステムに対するリバー関係や操作の意味を把握することができれば，リレーショ

スエンジニアリングにおいて，コード片とアクセスされる

ナルデータベースの操作（SQL 文）として効率よく同一のデータベースの関係を抽出する手法を提案している．レガ意味を持つ処理を再実装するといった活動を行うことが可

シーシステムのモダナイゼーションを行う際，元のすべて能となる．

のコードが新システムにおいて使用されるとは限らない．

本研究では，バッチシステムの動作の概要を抽出する技

一部のコードのみが新システムに移行されるとき，手法に術の 1 つとして，1 つのバッチ処理を構成するプログラム

よりソースコードの移行と併せて必要なデータベースの移群から，システム外部との入出力となるデータセット (バッ行を行うことが可能となる．手法はアーキテクチャ駆動モ

チシステムにおけるデータの系列) 群を抽出し，どの入力

ダナイゼーションと呼ばれるフレームワークに基づいてお

データセットの値を使ってどの出力データセットの値を計り，ソースコードやデータベースなどはすべてモデル化さ算しているかのデータフロー関係を表形式で可視化する手れたのち，分析される．

法を構築した．具体的なアプローチとしては，ジョブ制御

Bao ら [8] は，レガシーシステムのなかでも比較的新し

言語の記述から COBOL プログラムの実行順序と各プログ

いオブジェクト指向言語によって書かれたシステムのモダラムにおいて使用するデータセット名称を抽出し，ジョブ

ナイゼーションのための，機能単位の抽出手法を提案して制御言語上でのデータ依存グラフを構築する方法を定義しいる．この手法では，ソースコードのほかに仕様書を用いた．また，複雑化したひとつの COBOL プログラムが互る必要がある．ユースケースから機能ごとのテストケース

いに無関係な複数の処理を実装している場合に対応するたを生成し，そのテストケースの実行時のログを記録する．

め，COBOL のデータ構造に対応したプログラムスライシ

その後，ログに含まれるクラスやメソッドを解析することング手法を導入し，ジョブ制御言語上でのデータ依存関係

で，機能に対応するコード片の抽出を行うという，動的なのより正確な計算を可能とした．

手法に基づくものである．

提案手法の有効性を調査するために，ケーススタディとWiggerts ら [9] は，レガシーな COBOL プログラムからして，ある企業で利用されているバッチ処理システムのすべ

Object-Oriented COBOL へ変換するため，COBOL プロてのバッチに対して手法を適用した．その結果から，デーグラムからオブジェクトを識別する手法をまとめている．

©2016 Information Processing Society of Japan15

ソフトウェアエンジニアリングシンポジウム 2016
IPSJ/SIGSE Software Engineering Symposium (SES2016)

この研究によると，COBOL プログラムからオブジェクト

バッチ処理は，ジョブ制御言語で記述され，メインフを見つけ出す方法は大きく分けて function-driven，data-

レームコンピュータ上で実行されるデータ加工の手続きでdriven, object-driven の 3 つに分類される．本研究では，ある．システム全体では複数のバッチ処理を実現し，日次

バッチ処理システムにおけるデータセットのデータ依存関や月次といった様々なタイミングで実行するが，本研究で係に着目しているという点で，data-driven のアプローチ

は一連のジョブをまとめて実行するジョブネットという単に当てはまる．

位を 1 つのバッチ処理とみなして解析する．

プログラムスライシング [10] は，プログラム中の特定の

1 つのジョブネットは，実行するべき関連ジョブを複数文が出力する変数の値に関係を持つプログラム文の集合（多い場合は数万件）列挙し，それらの実行順序の制約を指を計算する技術である．Horwitz ら [11] により，制御依存定したものである．各ジョブは，さらにその構成要素であ関係，データ依存関係を用いたグラフ構造上での探索問題

るジョブステップの並びによって定義され，業務システム

として定義されており，本研究では COBOL 用のデータの場合，各ジョブステップの多くは COBOL プログラム

依存解析として Stap の手法 [12] を用いてグラフの構築をから構成される [16]．そのため，本研究ではジョブ制御言行った．

語と COBOL プログラムのみを解析対象とする．

Ákos ら [13] は，業務システムにおける大規模な COBOL

本研究では，解析対象となるジョブネット全体をジョブプログラムに対するプログラムスライシング手法を提案しステップの集合 S と，ジョブステップ間に存在する順序ている．この手法は制御フローグラフ上においてトークン

制約 si → sj (si , sj ∈ S) の集合として取り扱う．順序制約を伝播させていくというアプローチを用いることで，一般

si → sj は，si の実行が完了してから sj を実行すること的な制御依存グラフを用いたスライシングと同程度の精度を意味しており，たとえば 3 つのジョブステップ s1 , s2 , s3を保ちながら，より効率のよいスライシング計算を実現しに対して s1 → s3 かつ s2 → s3 であれば，s1 と s2 の実行

てる．本研究では，手法において COBOL プログラムのスが完了するまでは s3 の実行は開始されないことを意味す

ライシング計算を行うが，対象となるシステムの COBOL

る．s1 と s2 の間には順序制約が指定されていないので，プログラムの規模が一般的なスライシング手法であってもこれらはジョブ管理システムによって並行に実行される可問題なく計算できる範囲であったため，Ákos らの手法は能性がある．ジョブ制御言語の記述では繰り返し処理は存用いていない．

在しないため，順序制約でジョブステップを連結したもの

Hatano ら [14] は，Java で書かれたシステムにおいて，

は有向非巡回グラフとなる．

1 つのメソッド内部に記述されたビジネスロジックの出力

バッチ処理を構成するジョブステップ s ∈ S は，入力に影響を与えるような条件文を特定する手法をプログラム

データセットの集合 R(s) を使用して COBOL プログラム

スライシングを使用して実現した．本研究の提案手法は，を実行し，計算結果を出力データセットの集合 W (s) にジョブ制御言語によって連結された複数の COBOL プロ

書き出す処理を行う．各データセットは，複数のデータ項

グラムの中でのデータフローを抽出しており，また，条件目から構成されるレコードの並びであり，他のバッチ処理

分岐ではなく入出力となるデータ間の関係を抽出する手法

からの入力，ジョブステップ間でのデータの受け渡し，他となっている．

のバッチ処理への出力はすべてデータセットの読み書きとMeyers ら [15] は，1 つの手続き単位が複数の出力変数して行われる．使用されるデータセットの名称はジョブ制を書き出すとき，それぞれの出力変数に対して計算したプ御言語から取得することができ，読み書きのどちらとしてログラムスライスが共通の文を多く含むほどその手続き

データセットを使用するかは COBOL プログラムの記述の凝集度が高いと解釈することを提案している．本研究でから得られる．

は，COBOL プログラムを出力データごとのプログラムス

解析の入力例として，図 1 に 1 つのジョブネットを構

ライスに分解して個別に解析することで，凝集度が低い

成するジョブ制御言語の記述から抽出されるジョブステッ

COBOL プログラムが解析結果の正確さを損なわないよう

プ群とその実行順序を示す．図中で長方形で示されているにした．

ものがジョブステップであり，それを囲む線がジョブであ3. 提案手法

る．辺はジョブステップの実行順序関係を表しており，この図では最初のジョブステップが終了した後，2 つの計算本研究では，バッチ処理を構成するジョブ制御言語の記が並行して進行することが示されている．ジョブ制御言語

述と COBOL プログラム群の内容から，そのバッチが行うは図 1 左のようにジョブ間の順序を指定するが，本研究で計算の概要として，バッチ処理全体の初期入力となるデーはこれを図 1 右のようにジョブステップを頂点としたグラ

タセットの一覧，最終出力となるデータセットの一覧と，

フとして使用する．図 1 右のグラフでは頂点のラベルとし

どの入力データセットがどの出力データセットの計算に関て入出力データセットの名称を付与しており，たとえば最係するかを表現した対応表を出力する手法を提案する．

初のジョブステップは，データセット A を入力としてデー©2016 Information Processing Society of Japan16

ソフトウェアエンジニアリングシンポジウム 2016
IPSJ/SIGSE Software Engineering Symposium (SES2016)

read A
write D,F

図 1 に示したジョブネットが入力として与えられた場

read A
write D,F合，提案手法は，初期入力データセットが A, B, C，最終
出力データセットが H, I, J であると認識し，それらの間

read B,C,D
write E,H

read E
write I

図1

read B,C,D
write E,I

read F
write G
read G
write J,Kの依存関係として表 1 を抽出する．この表から，これらのread F
write G
read G
write J

read E
write H

データセットが他のバッチ処理や外部システムと関係する
重要なデータセットであり，データセット A, B, C の内容を用いてデータセット H, I の内容を，データセット A の内容からデータセット J の内容を計算していることが分か

左はジョブ制御言語で記述されるジョブ間の順序制約の例，右る．このような情報を複数のバッチから収集していくことはそれに対応するジョブステップ間の実行順序制約グラフでで，システム全体で重要な役割を持つデータセットや，そある．長方形がジョブステップであり，ラベルはジョブステッ
プが入出力するデータセットの集合を示す．ジョブステップを囲む破線はジョブ単位を示す．

れらの関係を明らかにし，システムの再設計の手がかりを得ることができる．提案手法の出力として表形式を採用した理由は，バッチシステムを構成する膨大な数の要素の情表 1

提案手法の出力例．初期入力とはジョブネットの内部で出力報を，抽象度の高い表現に集約するためである．「各ジョなしに参照されるデータセット，最終出力はジョブネットの内ブネットがどのデータセットからどのデータセットを生部で出力された後参照されないデータセットである．
初期入力 A
初期入力 B
初期入力 C成するか」という情報から個々のバッチの役割や，複数の最終出力 H✓✓✓

最終出力 I✓✓✓

最終出力 J✓

バッチ間の関係を分析することが，システム全体の構造の理解と再設計に重要であると考えた．バッチシステムにおける各プログラムの振る舞い，たとえば，各プログラムがどのデータセットを扱っているかという情報を出力に付与

タセット D, F を出力することを表現している．

することや，それらの関係を表現したグラフを出力するこ本研究では，バッチ処理に登場するデータセットを，バッとは可能である．しかし，これらの情報はシステムの規模

チ処理内部での読み書きの情報に基づいて次の 3 つに分類

（COBOL プログラムの数）に比例して量が増加するため，する．

人間にとって理解が困難となることが予想される．そこで初期入力データセット あるジョブステップ s において読本研究では，ジョブネット単位での動作の概要のみを表形

み込まれるが，順序制約によって s より前に実行されるどのジョブステップの出力データセットにも含まれ式で出力するものとした．
提案手法は，以下の手順からなる．

ないようなデータセットを，他のバッチ処理から与え( 1 ) ジョブ制御言語の記述から実行順序グラフを作成する．

られる入力であるとみなす．

( 2 ) ジョブステップごとの COBOL プログラムのスライ

最終出力データセット あるジョブステップ s において書

シング情報を使って実行順序グラフを詳細化する．

き込まれた後に，順序制約によって s より後に実行さ( 3 ) 実行順序グラフの情報を用いて初期入力データセッ

れるどのジョブステップにも読み込まれるようなこと

ト，最終出力データセットを識別し，実行順序グラフがないデータセットを，他のバッチ処理に提供する出力であるとみなす．
中間データセット あるジョブステップにおいて書き込みにそれらを表現するノードを追加する．

( 4 ) 実行順序グラフ上でデータ依存関係を計算し，データ依存グラフを構築する．

が行われた後，他のジョブステップによって読み込み( 5 ) データ依存グラフを用いて，初期入力データセットとが行われるデータセットは，そのデータセット自体は最終出力データセットの間のデータ依存関係を計算機能としての意味を持たず，他のデータの生成のため

し，表形式で出力する．

の中間的なデータセットとみなす．

なお，ステップ 2 の計算は計算の正確さを向上するため

上記の分類により，1 つのバッチ処理を，初期入力データに導入しているが必須ではなく，COBOL プログラム中のセットから最終出力データセットを計算する一連の処理でファイル操作の文を解析するだけでも出力を得ることが可あるとみなす．ただし，ジョブネット内において読み込ま能である．COBOL には様々なコンパイラ依存の言語要素れたのち，書き込みが行われるようなデータセットは初期もあり，解析が不可能なファイルなどについてはこの詳細

入力データセットかつ最終出力データセットになりうるた化のステップを飛ばして実行できるようになっている．以め，初期入力データセット集合と最終出力データセット集

降の節では，各ステップの詳細について順番に説明する．

合には共通のデータセットが含まれる可能性がある．一方
で，中間データセット集合は，初期入力，最終出力のいずれとも排反である．

©2016 Information Processing Society of Japan

3.1 実行順序グラフの作成
提案手法では，最初にジョブ制御言語の記述内容を解析

17

ソフトウェアエンジニアリングシンポジウム 2016
IPSJ/SIGSE Software Engineering Symposium (SES2016)

B

C

D

B

C

D

read A
write D,F

read B,C,D
write E,I

E

I

E

I

read A
write D

read F
write G

read B,C
write E

read G
write J

図 2

(左図) 実際のデータ依存関係 (右図) ジョブ制御言語の情報だread E
write H

read D
write I

read A
write F

read F
write G
read G
write J

read E
write Hけから推定されるデータ依存関係
図 3

実行順序グラフの詳細化．左図は詳細化前，右図は詳細化後．

し，実行順序グラフを作成する．実行順序グラフは有向グ
ラフであり，ノードは 1 つのジョブネット内部のすべてのする．2 つの処理は本来は独立であるが，何らかの理由でジョブステップ，辺はそれらの間の実行順序の制約に対応

単一プログラムに処理が記述されてしまうと，本来は図 2

する．1 つのジョブ内に定義されているジョブステップはの左図のような入出力関係であるにもかかわらず，ジョブ

逐次的に実行されるため，ジョブ j1 の実行後に j2 を実行

制御言語の記述と COBOL の OPEN 文からは右図のようするという順序関係は，j1 の末尾のジョブステップ s1 とな入出力関係が推定されてしまう．

j2 の先頭のジョブステップ s2 の間の順序関係として解釈
してジョブステップ間の順序関係を接続する．

本研究ではこの問題を解決するために，COBOL プログ
ラムが複数の出力データセットを持つ場合，図 3 のようにバッチ処理を構成するジョブステップ s ∈ S は，ジョブ各出力ファイルに対応した部分プログラムへと自動的に分制御言語の記述で指定されたデータセットの集合を用いて解し，各ノードが高々 1 つの出力データセットを持つグラ

COBOL プログラムを実行する．COBOL プログラム中でフへと詳細化を行う．図 2 の例では，B，C を入力としては，使用するデータセットは OPEN 文によって宣言されE を出力とする部分プログラムと，D を入力として I をる．OPEN 文にはオープンモードの指定があり， INPUT

出力とする部分プログラムにノードを分割する．詳細化前

は読み込み専用， OUTPUT は書き込み専用，I-O であれのグラフにおいてジョブステップ s1 からジョブステップ

ば入出力の可能性があることを意味する．これらの情報を

s2 への辺があった場合は，s1 に対応するすべてのノード

正規表現による検索により抽出し，ジョブ制御言語で記述

群から s2 に対応するすべてのノード群へと辺を接続する．

されたすべてのデータセットの集合を，データを読み込む

図 3 の場合は，A を入力として D，F を出力する 2 つの部

入力データセットの集合 R(s) と計算結果を書き出す出力分プログラムが先に実行され，そのあとで 3 つのプログラ

データセットの集合 W (s) に分類する．これらをグラフのムが実行されるというように 6 本の辺を接続することで，ノードのラベルとして付与すると，図 1 に示すようなグラ

詳細化前の実行順序関係をそのまま保存しておく．

フが得られる．

部分プログラムの計算は，プログラムスライシング [10]によって行う．COBOL プログラムでは出力が WRITE 文

3.2 COBOL プログラムのスライシング解析による実行
順序グラフの詳細化

によって行われているため，1 つのデータセットに対応す
る WRITE 文の集合をスライシング基準としてプログラ

1 つのジョブステップは複数のデータセットを入力とし，ムスライスを求めると，WRITE 文で書き込まれるレコー

複数のデータセットを出力することができる．一般的に

ドの内容に影響を与える可能性があるすべての文の集合

は，すべての入力データセットの内容がすべての出力デーを求めることができる．得られたスライスの中に含まれる

タセットの内容に影響を与えると仮定するのが自然であREAD 文によって読み込まれるデータセットが，その部分る．しかしながら，業務システムにおける COBOL プログ

プログラムにとっての入力データセットとなる．

ラムは巨大化・複雑化している傾向があり，1 つのプログ

COBOL のプログラムスライシングに用いるデータ依存

ラムに複数の機能が混在していることがあると経験的に判解析には，Stap の手法 [12] を用いた．COBOL における明している．このような COBOL プログラムでは，直接変数は入れ子構造を持つ可能性がある項目として定義さ的に関係のないデータセットの読み込みと書き込みが混在

れ，それ以上小さな項目単位へ分割できない項目は基本項しており，実際には無関係なデータセット間に関係がある目と呼ばれる．また，基本項目をまとめた最上位の項目をとみなしてしまう可能性がある．

レコード呼ぶ．たとえば，以下の変数の宣言では，DATE

図 2 は，無関係なデータセットの間に関係があるとみながレコードであり，YEAR，MONTH，DAY という項目かされるジョブステップの例を示したものである．このジョら構成される．YEAR，MONTH，DAY はそれ以上分割

ブステップはデータセット B，C を読み込んで計算した結できないため，基本項目である．

果を E に出力し，D を読み込んで計算した結果を I に出力©2016 Information Processing Society of Japan18

ソフトウェアエンジニアリングシンポジウム 2016
IPSJ/SIGSE Software Engineering Symposium (SES2016)

01 DATE.
05 YEARentry C

entry BPIC 9(4).

A
read A
write D,F

B

C

05 MONTH PIC 9(2).
05 DAY

entry A

read A
write D,F

D

PIC 9(2).

この宣言を持つ COBOL プログラムにおいて，レコード

read B,C,D
write E,I

read F
write GDATE への変数の代入が行われるとき，その子となる基本項目すべてが上書きされる可能性がある．そのため，

COBOL プログラム中における変数に対するすべての操作を，その変数の子となる基本項目へ展開して解析を行うことで正確さを保っている．また，サブルーチン呼び出しについても対応した解析を行っている．

read G
write J

read F
write GG
read G
write J

I

E

read E
write HF

read B,C,D
write E,I

read E
write HJ

I
exit H

exit I

exit J図 4 図 1 のグラフから COBOL プログラムの解析による詳細化なしで計算した場合のデータ依存グラフ．灰色の長方形は初期入力，最終出力データセットに対応する仮想的なノードである．

3.3 初期入力と最終出力の識別

entry C
read A
write D

実行順序グラフとして表現されたジョブステップ（あるread A
write F

entry B

read A
write D

D
read B,C
write E

期入力データセット集合 I ，最終出力データセット集合 Oを求める．I はジョブネット内部で書き込みなしに読み出されるデータセット，O は書き出された結果が読み込まれないデータセットである．具体的には，実行順序グラフ上であるジョブステップ s1 から s2 に辺を 1 つ以上たどって∗

read D
write I

read B,C
write E

read F
write G

read E
write H

read A
write F

F

read D
write I

read F
write G

E

G
I

read G
write JA

B

いはその一部）が行う入出力データセットと，その順序情報が得られているので，それらを使ってジョブネットの初

entry AA

C

read G
write J

read E
write HJ

H
exit H

exit I

exit J図 5 図 3 のグラフから COBOL プログラムの解析による詳細化ありで計算した場合のデータ依存グラフ．

到達可能であることを s1 −→ s2 と表現すると，I ，O は，それぞれ以下のようなデータセット集合に対応する．
′

′ ∗

′

I = {i|∃s.i ∈ R(s) ∧ ∀s (s −→ s).i ∈/ W (s )}∗O = {o|∃s.o ∈ W (s) ∧ ∀s′ (s −→ s′ ).o ∈/ R(s′ )}を構築する．これらの図において初期入力データセットは
データセット A, B, C であり，最終生成データセットは
データセット H, I, J である．それぞれ entry, exit という仮想的な入出力ノードで表現される．
実行順序グラフにおけるジョブステップ間のデータ依存

これらのデータセットはバッチ処理内部に対応する入出力

関係の計算は，一般的なプログラムに対する def -use 関係を持たないため，そのままではデータ依存グラフ上に情報の計算と以下の 2 点で異なる．1 つ目は，データセットへが表現されない．そのため，以下のように仮想的な入出力の出力操作は一般的なプログラムにおけるファイルへの追ノードを実行順序グラフに追加する．

記に相当する場合があるという点である．通常の def -use

• 各初期入力データセット i ∈ I に対して，すべてのの計算であれば変数への値の代入が元の値を上書きするとジョブステップよりも先に実行される entryi ノード

考えるが，ファイルへの追記は過去に出力された値を上書を作成し，R(entryi ) = ϕ, W (entryi ) = {i} とする．

きしないため，あるジョブステップ s が出力したデータ• 各最終出力データセット o ∈ O に対して，すべてのセットの内容は s より後に実行されるすべてのジョブに届

ジョブステップよりも後に実行される exito ノードをくと仮定する．2 つ目は，実行順序グラフ上での経路の分作成し，R(exito ) = {o}, W (exito ) = ϕ とする．

岐は並行での実行を表現しているだけであり，分岐先のす

これにより，すべてのデータセットのデータ依存関係が実べてのプログラムが必ず実行されるという点である．厳密

行順序グラフ上で計算可能となる．

な def -use を計算するのであれば，一般的なプログラムにおけるマルチスレッド処理の解析と同じように，並行実行

3.4 データ依存グラフの構築

されるプログラム間のあらゆる順序関係を考慮する必要が本ステップでは，ジョブステップ間におけるデータの依ある．この点については，本研究では，同一データセット

存関係を表したデータ依存グラフを構築する．本手順の過を扱うジョブステップについて，必ずそれらの実行順序が程を図 4, 図 5 に示す．図 4 は COBOL プログラムの解析

定義されていることを仮定している．一般には，s1 と s2の詳細化を行わなかったときの例であり, 図 5 は詳細化をの間に順序制約がないにもかかわらず W (s1 ) ∩ R(s2 ) ̸= ϕ

行ったときの例である．それぞれの左図は前ステップまでが成立するようなジョブ制御言語の記述は可能であるが，で求めたラベル付きの実行順序グラフであり，これらからジョブ実行時の順序関係によってデータ依存関係が変化す

右図のようなジョブステップ間におけるデータ依存グラフ

るようなシステムはレガシーシステムとして運用されてい©2016 Information Processing Society of Japan19

ソフトウェアエンジニアリングシンポジウム 2016
IPSJ/SIGSE Software Engineering Symposium (SES2016)

表 2

データ依存グラフの詳細化を行ったときの提案手法の出力となる対応表の例．
初期入力 A

最終出力 H

表 3

ジョブネットにおける各データセットの数の調査結果．|I| は
初期入力データセットの数，|O| は最終出力データセットの初期入力 B

初期入力 C✓✓

数，|M | は中間データセットの数．|I ∪ O ∪ M | はジョブネッ

最終出力 I✓トで使用されるすべてのデータセットの総数である．
|I||O| |M ||I ∪ O ∪ M |最終出力 J

✓

Min.

1.0

1.0

0.0

2.0

Median

81.0

117.0

0.0

308.0

る業務システムには存在しないと仮定している．これら 2

Mean

317.1

283.6

1.5

602.0

つの仮定に従って，本手法では，以下の条件をすべて満た

Max.

951.0

760.0

117.0

1711.0

したとき，2 つのジョブステップ s1 , s2 間にデータ依存関係が存在すると判断する．

• s1 が出力したデータセット d が s2 の入力データセッ
トである．すなわち，W (s1 ) ∩ R(s2 ) ̸= ϕ である．

る詳細化ありで求めたとき，(2) の値から減少する度
合い．

( 4 ) 対応表の形状の特徴．

• s1 が実行された後で s2 が実行されることがジョブ制(1) はレガシーシステムにおけるジョブネットの規模と特御言語で指定されている．すなわち， 実行順序グラフ

性を調べるものであり，(2) と (3) は対応表の可視化の有∗上で s1 −
→ s2 である．
結果として得られるデータ依存グラフは，実行順序グラ
フと同じノード集合を持ち，データ依存関係を辺とする有向グラフとなる．実行順序の関係そのものは，データ依存
グラフには含めない．

効性と，COBOL の解析を導入した効果をそれぞれ定量的に調べるものである．(4) は，得られた対応表の一部に対する目視での定性的な調査である．
ケーススタディは，実際に企業で稼働しているバッチ処
理システムのすべてのジョブネットに対し，手法を適用することで実施した．対象システムは金融機関において融資

3.5 入出力の対応表の抽出業務を行うものであり，2000 年にメインフレーム上に作

初期入力データセット i ∈ I と最終出力データセット

成されたものである．ジョブステップに対応するプログラo ∈ O の間に関係がある（o の計算に i が使用されている）

ムの多くは COBOL で記述されているが，一部のジョブス

かどうかは，データ依存グラフ上で，初期入力データセッ

テップに対応するプログラムはメインフレームコンピュート i に対応する entryi ノードから最終出力データセット

タのユーティリティ・プログラムである．ユーティリティ・

o に対応する exito ノードへのデータ依存辺の推移的な経プログラムはデータセットのソートやコピーなど，基本的路が存在するかどうかによって求める．

な操作を扱うプログラムであるが，メインフレームコン

この対応関係を表 1, 表 2 のような対応表にまとめたも

ピュータ依存の処理であるため，今回の評価実験ではそれのを手法の出力とする．COBOL プログラムの解析の詳細

らのジョブステップは R(s) = W (s) = ϕ として扱うこと化を行わなかった図 4 のデータ依存グラフから得られる対

で解析の対象外とした．

応表が表 1 であり，詳細化を行った図 5 から得られる対

以下，各項目の評価結果と考察を順番に述べる．

応表が表 2 である．表 1 に示された ✓ が 7 個あるのに対し，表 2 に示された ✓ が 4 個にまで減少している．これ

4.1 ジョブネットにおけるデータセット数

は COBOL プログラムをスライシングで分解することによ

提案手法を用いて，ジョブネットで使用されるデータ

り，最終出力データセットの生成に実際は不必要である初セットの集合を初期入力データセット集合 I ，最終出力

期入力データセットが対応表から取り除かれたことを意味

データセット O，中間データセット M の 3 つに分類し，する．

それぞれの集合のサイズを計算した．

4. ケーススタディ

ジョブネットにおける各データセットの数の最小値，中央値，平均値，最大値を表 3 に示す．中間データセットの提案手法を実装し，実際のバッチ処理システムに対し手数は他のデータセットの数に比べて小さい傾向が読み取れ法を適用して効果を確認するケーススタディを行った．こる．中間データセットはジョブネット内において書き込みのケーススタディで調査する項目は次の通りである．

が行われた後，読み込みが行われるデータセットである．

( 1 ) ジョブネットにおける初期入力，最終出力，中間デー

中間データセットが少ないということは，ジョブネットにタセットの数．

おいて，初期入力となるデータセットが読み込まれて何ら( 2 ) 対応表の大きさに対する，実際に対応関係があるデー

かの処理が実行され，その結果がそのままジョブネットのタセットの組み合わせの割合を，COBOL プログラム

最終出力として書き出されるようなデータの流れが多くをの解析による詳細化なしで求めたもの．

占めるということを意味する．

( 3 ) (2) と同様の割合を，COBOL プログラムの解析によ©2016 Information Processing Society of Japan

ジョブネット内における一時的なデータセットを中間

20

0.8
0.6

0

0.2

200

0.4

rd

400

# of O

600

1.0

ソフトウェアエンジニアリングシンポジウム 2016
IPSJ/SIGSE Software Engineering Symposium (SES2016)

0

200

400

600

101

800

102

103

104

ジョブネットごとのデータセット数．横軸：初期入力データ
セット数，縦軸：最終出力データセット数．

データセットとみなし，対応関係表から除外することで，出力対応表の大きさを抑え込めることを期待していたが，今回の適用対象システムでは，この工夫により実際に出力

106

107

| I ||O|# of I

図 6

105

図 7

ジョブネットの規模に対する rd の値．横軸:対応表の大きさ|I||O|，縦軸：rd の値．
表 4 全ジョブネットにおける rd の値
Min. Median Mean Max.

0.04

0.52

0.59

1.00

から除外可能なデータセットは比較的少なく，有効な場合は少ないといえる．
ただし，中には 100 以上の中間データセットをもつジョrd =n(I, O)|I||O|

ブネットも存在しており，このようなジョブネットに対し

ここで，n(I, O) は初期入力データセット集合 I ，最終出ては，すべての書き込みデータセットを出力とする場合に力データセット集合 O の間で依存関係のある I と O 組

くらべ，100 以上の機能として本質的でない書き込みデー

み合わせ数である．つまり，n(I, O) は対応表に記されたタセットを除外することが可能であり，この工夫による貢チェックマーク（✓）の数に一致する．分母の |I||O| は献が大きいと考えれられる．

出力となる対応表のマス目の数であり，rd はチェック

また，ジョブネットにおける初期入力データセット数とマークが埋められている割合に対応する．たとえば，表 1

最終出力データセット数の関係性を散布図で示したものをの例では rd = 7/(3 × 3) = 0.78 となり，表 2 の例では

図 6 に示す．この図から，ジョブネットにおいて初期入力

rd = 4/(3 × 3) = 0.44 となる．

データセット数と最終出力データセット数の間に正の相関

rd の値の最小値，中央値，平均値，最大値を表 4 に示が見られることが確認できる．つまり，ジョブネットの最す．対象システムにおいて，rd の値は平均的に 6 割程度で終出力データセットが多いものは，その生成に必要な初期あった．ジョブネットの最終出力となるデータセットに対入力データセットも多い傾向があるといえる．ジョブネッ

し，その生成に必要となる初期入力データセットは平均的

トのなかには，初期入力データセット数が最終出力データには全体のうち 6 割程度であるため，あるジョブネットのセット数より極端に大きくなるものや，その逆となるもの

読み書きするデータセットの集合から，単純に I のすべがある．初期入力データセット数の方が極端に大きいものての要素が O のすべての要素の計算に使われていると解は，複数のデータセットからひとつのデータセットへデー

釈してしまうと，中間データセット数が少ないことを考慮

タを集積するような働きをするものであり，最終出力デーに入れたとしても，その半数近くが実際には依存関係のな

タセット数の方が極端に大きいものは，ひとつのデータ

い組み合わせであるということを意味する．したがって，セットから複数のデータセットへデータを振り分けている

提案手法のようにジョブの実行順序関係を考慮したデータ

ような働きをするものであると考えられる．

依存関係を求めることは，実際には依存関係のないデータセットを除外するのに有効であると考えられる．

4.2 対応表の大きさに対する対応関係があるデータセッ
トの組み合わせの割合

また，対応表の規模に対する rd の値を図 7 に示す．横軸は対応表の大きさ |I||O| であり，対数のスケールになっ提案手法の出力は，ジョブネットにおける最終出力デーている．この図からは，対応表の大きさと rd の相関は見らタセットと，その生成に必要な初期入力データセットの対れず，対応表の大きさに対し一様に効果が見られた．つま

応表である．最終出力データセットと初期入力データセッ

り，対応表の大きさによらず，手法は有効であると考えら

トのすべての組み合わせに対し，この対応関係が存在するれる．今回の対象システムから得られた対応表のなかで，ものの割合を調査するため，全ジョブネットに対し，以下最も大きいものは 72 万個以上のマス目をもつものであっの式で定義される割合 rd を評価した．

た．このジョブネットに対する rd の値は 0.2 程度であるた©2016 Information Processing Society of Japan21

ソフトウェアエンジニアリングシンポジウム 2016
IPSJ/SIGSE Software Engineering Symposium (SES2016)

1.0

表6

ケーススタディで実際に見られた対応表の例．i1 − i9 ，o1 − o7

0.0

0.2

0.4

re

0.6

0.8

がそれぞれ初期入力，最終出力データセット．
i1
i2
i3
i4
i5
i6
i7
i8

0

50

100

150

o1

✓

✓

✓

✓

o2

✓

✓

✓

✓

o3

✓

✓

✓

✓

o4

✓

✓

✓

o5

✓

✓

✓

i9

o6

✓

✓

o7

✓

✓

200

Index of Jobnet

COBOL プログラムが明らかに巨大化・複雑化していると
図 8 各ジョブネットの re の値．横軸:ジョブネットに対する通し
番号，縦軸：re の値．

詳細化を行うことが有効であるという見解を得た．

表 5 全ジョブネットにおける re の値
Min. Median Mean Max.

0.32

分かっている場合にのみ，プログラムスライシングによる

1.00

0.99

1.00

め，単純に I と O のすべての組み合わせを考慮する場合に比べ，60 万近い依存関係の候補を手法により自動的に除外することができた．

4.4 対応表の形状の特徴
4.1 節の結果から，本手法の出力となるデータセットの対応表において膨大な数の初期入力データセットと最終出
力データセットが存在する場合があることが分かった．このような場合，人間がその出力から動作の概要を理解することは困難であると考えられる．しかし，複数の対応表の4.3 データ依存グラフの詳細化の有効性
本手法には COBOL のスライシングによるデータ依存グラフの詳細化を行うステップが存在する．この詳細化の有効性を調査するため，詳細化を行った場合と行わなかった場合の出力となる対応関係の数の比較を行った．具体的には，全ジョブネットに対し以下の式で定義される re の値を求めた．ここで，n(I, O) は詳細化を行わない場合の，n′ (I, O) は詳細化を行った場合の初期入力データセットと最終出力データセットの依存関係がある組み合わせ数で
ある．

′

re =

n (I, O)n(I, O)re の値は詳細化前後の組み合わせ数の比になっており，この値が 0 に近いほど詳細化の効果があり，1 に近いほど効
果がないことを示す．

内容を目視で確認したところ，表 6 に示すように，特定のデータセット間に密なデータ依存関係をもつような対応表が多くのジョブネットから得られていることが判明した．表 6 の例では，最終出力データセット o1 − o3 が初期
入力データセット i1 − i4 から生成され，同様に o4 − o5 が

i5 − i7 から，o6 − o7 が i8 − i9 から生成される．この場合，ひとつひとつの出力データセットの生成に必要な入力デー
タセットを提示するのではなく，データセットのグループ化を行い，3 つの出力データセット群それぞれに必要な入力データセット群を提示することで，ジョブネットが主に

3 つの処理を扱っているということを明確に表現できる可能性がある．

5. 妥当性への脅威
本研究ではバッチ処理システムの動作の概要を抽出する実験により得られた re の値の最小値，中央値，平均値，ために，データセットの依存関係に着目するというアプ

最大値を表 5 に，各ジョブネットの re の値を図 8 に示す．

ローチとっている．これはデータセットが動作の概要に対re の値は中央値で 1.00 となっている．また図 8 から読み応しているという前提によるものであるが，レガシーシス

取れるように，ほとんどのジョブネットにおいてスライシ

テムにおいては，ひとつのデータセットに互いに関係のなングによる詳細化の効果が見られなかった．これは対象シいデータが混在しているなど，データセット自体が複雑化

ステムにおける COBOL プログラムにおいて互いに関係のしている場合があり，そのようなシステムに対しては本手ない処理が混在しているものが少ないということを意味し法のアプローチが適当でない可能性がある．

ており，対象システムのプログラムの品質としては好ましい状態にあったと考えられる．

本手法ではジョブネット内において書き込みが行われた
後，読み込みが行われるデータセットを動作の概要に本質

一方で，処理が混在している COBOL プログラムを含的でない中間データセットと見なすことで，手法の出力か

む一部のジョブネットに対しては，データセット間の関係

ら除外している．しかしながら，ジョブ間に定義されていが半分以下に削減されており，大きな効果があったと考る順序関係は実行の前後関係が定義されているにすぎず，えられる．今回のケーススタディからは，対象システムの実際にバッチ処理として実行されるときには長時間の間隔©2016 Information Processing Society of Japan22

ソフトウェアエンジニアリングシンポジウム 2016
IPSJ/SIGSE Software Engineering Symposium (SES2016)

が空く場合がある．このような場合，その時点でのデータ

ば，入力クラスタと出力クラスタ間のデータ依存関係を提セットの内容は機能にとって重要な役割を果たすものであ示することができ，概要の理解のよりよい支援につながるる可能性がある．本手法ではこのようなデータセットまでと考えられる．本研究では，手法の出力がデータセット同も中間データセットとして扱っているため，重要なデータ

士の対応表であるため，データセット同士のクラスタリン

セットを出力から除外してる可能性がある．

グの方法としては Formal Concept Analysis[17] の適用を提案手法ではジョブ間でやりとりされるデータはデータ検討している．

セットのみであると限定しているが，実際のシステムでは本研究においてデータベースやユーティリティによる影

データベースアクセスによるデータの依存関係が生じる

響は考慮していない．これらの仮定がどの程度出力に影響可能性があり，本研究のケーススタディではその影響を考を与えているのかを定性的に評価することも今後の課題と慮していない．今回は解析の対象外としたが，アクセスすして挙げられる．具体的には，システムに精通した人間にるデータベースのテーブルを仮想的なデータセットとみよる評価や，仕様が明確になっているシステムに対する評なし，SQL の SELECT 文で使用されたものを入力データ

価実験などが考えられる．その評価の結果次第では，手法

セット，INSERT 文や UPDATE 文で使用されたものを出をデータベースやユーティリティ等に対応するように拡張

力データセットとするだけで，手法の解析対象に組み込むする必要があると考えている．また，提案手法の出力が持ことが可能である．

つ情報の有用性については，企業内部の有識者からの肯定

本研究ではジョブが COBOL プログラムで表現されてい的な意見を得ているが，実際に分析作業の効率などを測定ることを仮定したが，バッチシステムによっては，データしたわけではない．したがって，提案手法の入出力（外部セットのコピー操作などのユーティリティプログラムが使連携ファイル) が実際に動作の概要を理解することにどれ用される可能性がある．これらについては，データベース

だけ役に立つのかを調査することも，今後の課題として挙と同様，入出力データセットの表現に変換することができげられる．

れば提案手法で取り扱うことはできるが，ユーティリティ

謝辞

プログラムごとに対応する表現を用意する必要がある．

6. まとめと今後の課題
本研究では，レガシーシステムの１つであるバッチ処理の助成を受けたものです．
参考文献
[1]

システムの動作の概要を理解するため，ジョブネットにおけるジョブの実行順序を考慮し，データセット間の依存関[2]係を抽出する手法を提案した．また，COBOL プログラムのスライシングを用いることでデータ依存関係の詳細化を[3]行う方法も考案した．ケーススタディとして，実際に企業で稼働しているバッチ処理システムに対し手法を適用し，[4]評価実験を行った．結果として，手法の出力から除外する
中間データセットは他のデータセット数に比べ比較的少[5]ないこと，データ依存関係においてジョブ間における順序関係を考慮することが有効であることが分かった．また，

COBOL プログラムのスライシングによるデータ依存関係[6]の詳細化は，特定のジョブネットにのみ有効であることが分かった．データセットの対応表は規模が大きいが，特定のデータセット集合間に密にデータ依存関係があることが多かったため，データセットのクラスタリングによって対応表を小さく表現できる可能性があることが分かった．た[7]

だし，これらの知見は単一のシステムを対象にしたケース
スタディの結果であり，より一般的な有効性を評価するため，複数のシステムに対し同様の調査を行う必要がある．

[8]

今後の課題として，巨大な対応表に対し，データ依存関係をもとにデータセットのクラスタリングを行うことが挙げられる．類似したデータ依存関係の構造をもつデータセット同士をうまく同じクラスタにまとめることができれ©2016 Information Processing Society of Japan

本研究は JSPS 科研費 Nos.26280021, 15H02683[9]Bennett, K.: Legacy Systems: Coping with Success,IEEE Softw., Vol. 12, No. 1, pp. 19–23 (1995).
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).
一般社団法人日本情報システム・ユーザー協会 (JUAS):
ソフトウェアメトリックス調査 2012, 一般社団法人日本
情報システム・ユーザー協会 (JUAS) (2012).
Sneed, H. M.: Migrating from COBOL to Java, 26th
IEEE International Conference on Software Maintenance, pp. 1–7 (2010).
Mossienko, M.: Automated Cobol to Java recycling,
Proceedings of the Seventh European Conference On
Software Maintenance And Reengineering, pp. 40–50(2003).
Hasselbring, W., Reussner, R., Jaekel, H., Schlegelmilch,J., Teschke, T. and Krieghoﬀ, S.: The Dublo architecture pattern for smooth migration of business information systems: an experience report, Proceedings of the
26th International Conference on Software Engineering, pp. 117–126 (2004).
Peréz-Castillo, R., de Guzmán, I. G. R., Ávila Garcia, O.
and Piattini, M.: On the Use of ADM to Contextualize
Data on Legacy Source Code for Software Modernization, 16th Working Conference on Reverse Engineering,pp. 128–132 (2009).
Bao, L., Yin, C., He, W., Ge, J. and Chen, P.: Extracting
reusable services from legacy object-oriented systems,
IEEE International Conference on Software Maintenance, pp. 1–5 (2010).
Wiggerts, T., Bosma, H. and Fielt, E.: Scenarios for theidentification of objects in legacy systems, Proceedings of23ソフトウェアエンジニアリングシンポジウム 2016
IPSJ/SIGSE Software Engineering Symposium (SES2016)

[10]

[11]

[12]

[13]

[14]

[15]

[16]
[17]

the Fourth Working Conference on Reverse Engineering, pp. 24–32 (1997).
Weiser, M.: Program Slicing, Proceedings of the 5th International Conference on Software Engineering, pp.
439–449 (1981).
Horwitz, S., Reps, T. and Binkley, D.: Interprocedural
Slicing Using Dependence Graphs, ACM Transactions
on Programming Languages and Systems, Vol. 12, No. 1,
pp. 26–60 (1990).
Stap, G.: Cobol Data Flow Restructuring, Master’s
thesis, Free University of Amsterdam, the Netherlands(2005).
Ákos Hajnal and Forgács, I.: A demand-driven approach
to slicing legacy COBOL systems, Journal of Software
Maintenance, Vol. 24, pp. 67–82 (2012).
Hatano, T., Ishio, T., Okada, J., Sakata, Y. and Inoue,K.: Dependency-Based Extraction of Conditional Statements for Understanding Business Rules, IEICE Transactions on Information and Systems, Vol. E99-D, No. 4,
pp. 1117–1126 (2016).
Meyers, T. M. and Binkley, D.: An Empirical Studyof Slice-based Cohesion and Coupling Metrics, ACM
Transactions on Software Engineering Methodology,
Vol. 17, No. 1, pp. 2:1–2:27 (2007).
神居俊哉: メインフレーム実践ハンドブック, リックテレ
コム (2009).
Ganter, B. and Wille, R.: Formal Concept Analysis:
Mathematical Foundations, Springer-Verlag New York,Inc. (1997).

©2016 Information Processing Society of Japan

24