JP2018025852A - プログラム分析方法、プログラム分析装置および分析プログラム - Google Patents

Abstract

【課題】プログラム修正の効率化に資する情報を提供する。【解決手段】記憶部１１は、同一のファイルにアクセスする複数のプログラムを含むプログラム資産１３を記憶する。演算部１２は、プログラム資産１３からそれぞれがファイルに格納されるデータの構造を示すデータ構造定義文１４ａ，１４ｂ，１４ｃ，１４ｄ，１４ｅ，１４ｆを抽出する。演算部１２は、データ構造定義文１４ａ，１４ｂ，１４ｃ，１４ｄ，１４ｅ，１４ｆの間の比較に基づいてそれらデータ構造定義文をタイプ１５ａ，１５ｂ，１５ｃに分類し、タイプ１５ａ，１５ｂ，１５ｃそれぞれについて当該タイプに属するデータ構造定義文を使用するプログラムの数をカウントする。演算部１２は、タイプ１５ａ，１５ｂ，１５ｃの間のプログラムの数の分布を示す分布情報１６を出力する。【選択図】図１

Description

本発明はプログラム分析方法、プログラム分析装置および分析プログラムに関する。

情報処理システムで使用されるプログラムは、長期間の運用に伴って拡張や変更が繰り返されることが多い。その結果として、プログラムの記述方法に一貫性がなくなることや、実質的に同じ内容の命令文が様々なプログラムに重複して記述されることがあり、当該プログラムの保守性が低下してしまうことがある。保守性の低いプログラムを使用し続けると、プログラムの可読性が低いために保守作業量が増大し、保守コストが大きくなってしまう。そこで、保守性が低くなったプログラムの構造を見直して再設計し、保守コストが小さくなるようにプログラムを修正することがある。

プログラムの保守性が低くなる状況の１つとして、複数のプログラムが同一のファイルにアクセスする状況が挙げられる。ファイルにアクセスするプログラムには、当該ファイルから読み込むデータまたは当該ファイルに書き込むデータの構造を示すデータ構造定義文が記述されることがある。データ構造定義文では、例えば、１以上のデータ項目の項目名やデータ型が定義される。ここで、同じファイルにアクセスする複数のプログラムに、実質的に同じ内容のデータ構造定義文が記述されることが生じ得る。これら複数のプログラムのデータ構造定義文は、データ項目の項目名などが統一されていないために、互いに若干異なることがある。この状況では、ファイルに格納するデータの構造を変えようとすると各プログラムに応じた変更を行うことになり、プログラムの保守性が低くなる。

そこで、例えば、データ項目名の統一を支援するソフトウェア標準化方法が提案されている。提案のソフトウェア標準化方法では、同じファイルにアクセスする複数のプログラムに定義されたデータ項目名を抽出し、抽出したデータ項目名を列挙した画面を表示する。列挙されたデータ項目名を参考にしてユーザに標準データ項目名を入力させ、プログラム中のデータ項目名を標準データ項目名に自動的に置換する。

また、例えば、標準化装置が提案されている。提案の標準化装置は、同じファイルにアクセスする複数のプログラムに定義されたデータ項目名を抽出し、抽出したデータ項目名を列挙した画面を表示する。標準化装置は、列挙されたデータ項目名の中からユーザに標準データ項目名を選択させる。標準化装置は、ユーザが選択した標準データ項目名を元のプログラムとは異なる外部ファイルに保存し、プログラムに含まれるデータ構造定義文を削除し、当該外部ファイルを参照するようにプログラムを修正する。

また、例えば、プログラム修正支援装置が提案されている。提案のプログラム修正支援装置は、プログラムに定義されたデータ項目毎に、当該プログラムのロジック中で使用されている回数をカウントし、使用回数が多いデータ項目を検討候補としてユーザに提示する。また、例えば、リエンジニアリング支援装置が提案されている。提案のリエンジニアリング支援装置は、プログラムを分析し、プログラムで使用されるデータ項目それぞれについて、データ項目名などの定義が外部ファイルに記載されている割合などの各種指標値を算出する。リエンジニアリング支援装置は、算出した指標値を所定の業界標準値と比較することで、プログラムの修正に要する日数や資金を見積もる。

特開平６−１８７１３６号公報 特開平７−１０４９８９号公報 特開平１１−２６５２８５号公報 特開２００１−２６５６２５号公報

しかし、上記特許文献１，２に記載の技術においてユーザに提供される情報は、現在プログラムで使用されている複数通りのデータ項目名のみである。このため、プログラム修正の効率化に資する情報を提供するという点で改善の余地がある。

例えば、現在使用されている複数通りのデータ項目名の中から標準データ項目名を選択する場合において、何れを標準データ項目名として選択すればよいかの判断に役立つ何らかの情報が提供されることが好ましい。また、例えば、限られた時間で保守性改善効果の大きいプログラム修正を行いたい場合において、何れのデータ項目名を優先的に検討すればよいかの判断に役立つ何らかの情報が提供されることが好ましい。

１つの側面では、本発明は、プログラム修正の効率化に資する情報を提供できるプログラム分析方法、プログラム分析装置および分析プログラムを提供することを目的とする。

１つの態様では、コンピュータが実行するプログラム分析方法が提供される。同一のファイルにアクセスする複数のプログラムを含むプログラム資産から、それぞれがファイルに格納されるデータの構造を示す複数のデータ構造定義文を抽出する。複数のデータ構造定義文の間の比較に基づいて複数のデータ構造定義文を複数のタイプに分類し、複数のタイプそれぞれについて複数のプログラムのうち当該タイプに属するデータ構造定義文を使用するプログラムの数をカウントする。複数のタイプの間のプログラムの数の分布を示す分布情報を出力する。

また、１つの態様では、記憶部と演算部とを有するプログラム分析装置が提供される。また、１つの態様では、コンピュータに実行させる分析プログラムが提供される。

１つの側面では、プログラム修正の効率化に資する情報を提供できる。

第１の実施の形態のプログラム分析装置の例を示す図である。 プログラム分析装置のハードウェア例を示すブロック図である。 第１のレコード定義方法の例を示す図である。 第２のレコード定義方法の例を示す図である。 ＪＣＬファイルの例を示す図である。 ファイル参照テーブルの例を示す図である。 レコード定義のタイプ分類例を示す図である。 レコード定義のタイプ分類例を示す図（続き）である。 タイプ分類テーブルの例を示す図である。 レコード定義分布の第１の可視化例を示す図である。 レコード定義分布の第２の可視化例を示す図である。 プログラム修正効果の可視化例を示す図である。 プログラム分析装置の機能例を示すブロック図である。 プログラム分析の手順例を示すフローチャートである。 プログラム分析の手順例を示すフローチャート（続き）である。

以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
第１の実施の形態を説明する。

図１は、第１の実施の形態のプログラム分析装置の例を示す図である。
第１の実施の形態のプログラム分析装置１０は、既存のプログラム資産の保守性を向上させて情報処理システムの保守コストを低下させるときに使用される。プログラム分析装置１０は、既存のプログラム資産を分析し、プログラム資産の修正作業を支援する。プログラム分析装置１０は、ユーザが操作するクライアント装置でもよいし、クライアント装置からネットワーク経由でアクセスされるサーバ装置でもよい。

プログラム分析装置１０は、記憶部１１および演算部１２を有する。記憶部１１は、ＲＡＭ（Random Access Memory）などの揮発性半導体メモリでもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性ストレージでもよい。演算部１２は、例えば、ＣＰＵ（Central Processing Unit）やＤＳＰ（Digital Signal Processor）などのプロセッサである。ただし、演算部１２は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの特定用途の電子回路を含んでもよい。プロセッサは、ＲＡＭなどのメモリ（記憶部１１でもよい）に記憶されたプログラムを実行する。プログラムには、分析プログラムが含まれる。複数のプロセッサの集合（マルチプロセッサ）を「プロセッサ」と呼ぶこともある。

記憶部１１は、プログラム資産１３を記憶する。プログラム資産１３は、同一のファイルにアクセスする複数のプログラムを含む。これら複数のプログラムの一部または全部は、当該同一のファイルからデータを読み出すプログラムであってもよい。また、これら複数のプログラムの一部または全部は、当該同一のファイルにデータを書き込むプログラムであってもよい。プログラム資産１３に含まれるプログラムは、例えば、ＣＯＢＯＬなどのプログラミング言語によって記述されたソースプログラムである。

複数のプログラムそれぞれは、例えば、ファイルに格納されるデータ（読み出すデータまたは書き込むデータ）の構造を示すデータ構造定義文を含む。ただし、これら複数のプログラムの一部は、データ構造定義を記載した外部ファイルを参照するものであってもよい。データ構造定義を記載した外部ファイルをプログラムから参照することは、例えば、ＣＯＰＹ文やｉｎｃｌｕｄｅ文などを用いて行うことができる。プログラム資産１３は、このような外部ファイルを含んでもよい。データ構造定義文は、例えば、ファイルに格納されるデータに含まれる１以上のデータ項目を識別するための１以上のデータ項目名と、当該１以上のデータ項目に対応する１以上のデータ型とを含む。

プログラム資産１３の中には、同一のファイルに対して異なるデータ構造定義文を使用するプログラムが混在している。これは、例えば、プログラム資産１３の拡張や変更を繰り返す過程で、プログラム間でデータ項目名が統一されなかったことにより生じ得る。また、これは、例えば、処理ロジックを記述する都合上、既存のプログラムで使用しているデータ型とは異なるデータ型を用いて新たなプログラムを作成したことにより生じ得る。また、これは、例えば、２以上のデータ項目の集合を集団項目とみなし、集団項目に対して独自の集団項目名を定義したことにより生じ得る。

演算部１２は、記憶部１１に記憶されたプログラム資産１３を分析し、同一のファイルに対する異なるデータ構造定義文の使用状況を可視化する。演算部１２は、プログラム資産１３から、同一のファイルに格納されるデータの構造を示す複数のデータ構造定義文を抽出する。例えば、演算部１２は、プログラム資産１３から、図１に示すデータ構造定義文１４ａ，１４ｂ，１４ｃ，１４ｄ，１４ｅ，１４ｆを抽出する。

データ構造定義文１４ａ，１４ｂ，１４ｃ，１４ｄ，１４ｅ，１４ｆは、例えば、互いに異なるプログラムに記述されていたデータ構造定義文である。データ構造定義文１４ａ，１４ｄ，１４ｆは、データ項目名が「ｋｅｙ−ｉｔｅｍ」でありデータ型が「Ｘ（１０）」であることを示している。データ構造定義文１４ｂ，１４ｅは、データ項目名が「ｋｅｙ−ｉｔｅｍ」でありデータ型が「Ｎ（５）」であることを示している。データ構造定義文１４ｃは、データ項目名が「ｉｔｅｍ−０１」でありデータ型が「Ｘ（１０）」であることを示している。ここで、「Ｘ（１０）」は半角１０文字を表し、「Ｎ（５）」は全角５文字を表しており、両者は同じデータ長を示している。

演算部１２は、抽出した複数のデータ構造定義文の間の比較に基づいて、複数のデータ構造定義文を複数のタイプに分類する。例えば、演算部１２は、異なるデータ型を使用するデータ構造定義文を異なるタイプに分類する。また、例えば、演算部１２は、異なるデータ項目名を使用するデータ構造定義文を原則として異なるタイプに分類する。ただし、演算部１２は、データ項目名の一部分（例えば、接頭辞）のみ異なるデータ構造定義文など、類似するデータ項目名を使用するデータ構造定義文を同じタイプに分類してもよい。

上記のデータ構造定義文１４ａ，１４ｂ，１４ｃ，１４ｄ，１４ｅ，１４ｆは、例えば、タイプ１５ａ，１５ｂ，１５ｃに分類される。すなわち、データ構造定義文１４ａ，１４ｄ，１４ｆはタイプ１５ａに分類される。データ構造定義文１４ｂ，１４ｅはデータ型がタイプ１５ａと異なるため、タイプ１５ｂに分類される。データ構造定義文１４ｃはデータ項目名がタイプ１５ａ，１５ｂと異なるため、タイプ１５ｃに分類される。

演算部１２は、複数のタイプそれぞれについて、当該タイプに属するデータ構造定義文を使用するプログラムの数をカウントする。上記のタイプ１５ａのプログラム数は３、タイプ１５ｂのプログラム数は２、タイプ１５ｃのプログラム数は１である。

そして、演算部１２は、複数のタイプの間のプログラム数の分布を示す分布情報１６を出力する。例えば、演算部１２は、プログラム分析装置１０に接続されたディスプレイに分布情報１６を表示させる。また、例えば、演算部１２は、他の装置に分布情報１６を送信する。分布情報１６は、複数のタイプそれぞれのプログラム数を示すグラフ（例えば、積み上げ棒グラフ）であってもよい。また、分布情報１６は、複数のタイプの間のプログラム数の比を示すグラフ（例えば、円グラフ）であってもよい。演算部１２は、分布情報１６と併せて、各タイプに属するデータ構造定義文を出力してもよい。

第１の実施の形態のプログラム分析装置１０によれば、プログラム資産１３から同一のファイルに対する複数のデータ構造定義文が抽出され、抽出された複数のデータ構造定義文が比較されて複数のタイプに分類される。そして、複数のタイプそれぞれについて当該タイプに属するデータ構造定義文を使用するプログラムの数がカウントされ、複数のタイプの間のプログラム数の分布を示す分布情報１６が出力される。

これにより、同一のファイルに対する複数のデータ構造定義文の使用状況を可視化することができ、プログラム資産１３の修正の効率化に資する情報を提供することができる。例えば、複数のデータ構造定義文を集約する（例えば、データ項目名を統一する）にあたり、複数のタイプのうち最もプログラム数の多いタイプを標準データ構造定義文として選択することで、修正作業を効率化することができる。また、例えば、プログラム数の多いタイプを優先的に修正対象として検討することで、限られた時間の中で保守性改善効果の大きい修正作業を優先的に行うことが可能となる。

［第２の実施の形態］
次に、第２の実施の形態を説明する。
図２は、プログラム分析装置のハードウェア例を示すブロック図である。

プログラム分析装置１００は、ＣＰＵ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力信号処理部１０５、媒体リーダ１０６および通信インタフェース１０７を有する。ＣＰＵ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力信号処理部１０５、媒体リーダ１０６および通信インタフェース１０７は、バス１０８に接続されている。なお、プログラム分析装置１００は、第１の実施の形態のプログラム分析装置１０に対応する。ＲＡＭ１０２またはＨＤＤ１０３は、第１の実施の形態の記憶部１１に対応する。ＣＰＵ１０１は、第１の実施の形態の演算部１２に対応する。

ＣＰＵ１０１は、プログラムの命令を実行する演算回路を含むプロセッサである。ＣＰＵ１０１は、ＨＤＤ１０３に記憶されたプログラムやデータの少なくとも一部をＲＡＭ１０２にロードし、プログラムを実行する。なお、ＣＰＵ１０１は複数のプロセッサコアを備えてもよく、プログラム分析装置１００は複数のプロセッサを備えてもよく、以下で説明する処理を複数のプロセッサまたはプロセッサコアを用いて並列に実行してもよい。また、複数のプロセッサの集合（マルチプロセッサ）を「プロセッサ」と呼んでもよい。

ＲＡＭ１０２は、ＣＰＵ１０１が実行するプログラムやＣＰＵ１０１が演算に用いるデータを一時的に記憶する揮発性の半導体メモリである。なお、プログラム分析装置１００は、ＲＡＭ以外の種類のメモリを備えてもよく、複数個のメモリを備えてもよい。

ＨＤＤ１０３は、ＯＳ（Operating System）やミドルウェアやアプリケーションソフトウェアなどのソフトウェアのプログラム、および、データを記憶する不揮発性の記憶装置である。プログラムには、分析プログラムが含まれる。なお、プログラム分析装置１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の記憶装置を備えてもよく、複数の不揮発性の記憶装置を備えてもよい。

画像信号処理部１０４は、ＣＰＵ１０１からの命令に従って、プログラム分析装置１００に接続されたディスプレイ１１１に画像を出力する。ディスプレイ１１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイ、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）、プラズマディスプレイ（ＰＤＰ：Plasma Display Panel）、有機ＥＬ（ＯＥＬ：Organic Electro-Luminescence）ディスプレイなどを用いることができる。

入力信号処理部１０５は、プログラム分析装置１００に接続された入力デバイス１１２から入力信号を取得し、ＣＰＵ１０１に出力する。入力デバイス１１２としては、マウスやタッチパネルやタッチパッドやトラックボールなどのポインティングデバイス、キーボード、リモートコントローラ、ボタンスイッチなどを用いることができる。また、プログラム分析装置１００に、複数の種類の入力デバイスが接続されていてもよい。

媒体リーダ１０６は、記録媒体１１３に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体１１３として、例えば、磁気ディスク、光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）、半導体メモリなどを使用できる。磁気ディスクには、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤが含まれる。光ディスクには、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）が含まれる。

媒体リーダ１０６は、例えば、記録媒体１１３から読み取ったプログラムやデータを、ＲＡＭ１０２やＨＤＤ１０３などの他の記録媒体にコピーする。読み取られたプログラムは、例えば、ＣＰＵ１０１によって実行される。なお、記録媒体１１３は、可搬型記録媒体であってもよく、プログラムやデータの配布に用いられることがある。また、記録媒体１１３やＨＤＤ１０３を、コンピュータ読み取り可能な記録媒体と言うことがある。

通信インタフェース１０７は、ネットワーク１１４に接続され、ネットワーク１１４を介して他の装置と通信を行うインタフェースである。通信インタフェース１０７は、スイッチなどの通信装置とケーブルで接続される有線通信インタフェースでもよいし、基地局と無線リンクで接続される無線通信インタフェースでもよい。

次に、ファイルにアクセスするソースプログラムの記述方法について説明する。
図３は、第１のレコード定義方法の例を示す図である。
ソースプログラム１３１は、プログラミング言語としてＣＯＢＯＬを用いて記述されたソースプログラム（ソースコード）の例である。ソースプログラム１３１は、見出し部（ＩＤＥＮＴＩＦＩＣＡＴＩＯＮ ＤＩＶＩＳＯＮ）、環境部（ＥＮＶＩＲＯＮＭＥＮＴ ＤＩＶＩＳＩＯＮ）、データ部（ＤＡＴＡ ＤＩＶＩＳＩＯＮ）および手続き部（ＰＲＯＣＥＤＵＲＥ ＤＩＶＩＳＩＯＮ）を含む。

見出し部には、プログラム名が記述される。ソースプログラム１３１のプログラム名は「ＰＲＯＧＲＡＭ１」である。環境部には、アクセスするファイルの論理ファイル名と中間ファイル名との対応関係が記述される。論理ファイル名と中間ファイル名は何れも、ファイルシステムが使用する物理的なファイル名（実ファイル名）とは異なる仮想的なファイル名である。論理ファイル名は、データ部で使用されるファイル名である。中間ファイル名は、後述するジョブ制御言語（ＪＣＬ：Job Control Language）プログラムで使用されるファイル名である。ソースプログラム１３１がアクセスするファイルの論理ファイル名は「人事−ＲＥＣ」、中間ファイル名は「ＦＩＬＥ１」である。

データ部には、論理ファイル名と対応付けて、論理ファイル名が示すファイルに格納されるデータの構造を示すレコード定義が記述される。第２の実施の形態のレコード定義は、第１の実施の形態のデータ構造定義文に対応する。レコード定義は、ファイルに格納されるデータに含まれる１以上のレコード（データ項目）を示す。１つのレコードに対して、１つのデータ項目名と１つのデータ型とが定義される。ただし、処理ロジックを記述するのに好適な場合、２以上のレコードの集合に対し集団項目名が付与されることがある。

ソースプログラム１３１には、論理ファイル名「人事−ＲＥＣ」に対して、（従業員コード，Ｘ（５））、（所属コード，Ｘ（３））、（氏名，Ｎ（１０））というレコード定義が記述されている。データ型であるＸ（５）は５文字の半角文字列を表し、Ｘ（３）は３文字の半角文字列を表し、Ｎ（１０）は１０文字の全角文字列を表している。

手続き部には、データ部で定義されたレコード定義を利用した処理ロジックが記述される。手続き部には、論理ファイル名が示すファイルからデータを読み出す処理ロジックが記述されることがある。その場合、データ項目名を変数名として用いて、ファイルから読み出したデータを参照することができる。また、手続き部には、論理ファイル名が示すファイルにデータを書き込む処理ロジックが記述されることがある。その場合、データ項目名を変数名として用いて、ファイルに書き込むデータを生成することができる。

図４は、第２のレコード定義方法の例を示す図である。
ソースプログラム１３２は、図３のソースプログラム１３１と同様に、プログラミング言語としてＣＯＢＯＬを用いて記述されたソースプログラムの例である。ソースプログラム１３２の環境部には、ソースプログラム１３１と同様に、論理ファイル名「人事−ＲＥＣ」と中間ファイル名「ＦＩＬＥ１」が記述されている。すなわち、ソースプログラム１３２は、ソースプログラム１３１と同じファイルにアクセスすることがある。

ただし、ソースプログラム１３１と異なり、ソースプログラム１３２のデータ部にはレコード定義が直接記述されていない。その代わりに、ソースプログラム１３２のデータ部には、レコード定義ファイル１３３を参照するＣＯＰＹ文が記述されている。ＣＯＰＹ文は、参照先のレコード定義ファイルに記述されたレコード定義を取り込む命令文である。ソースプログラム１３２は、ファイル名が「人事ＲＥＣファイル」であるレコード定義ファイル１３３のレコード定義をデータ部に取り込んでいる。

レコード定義ファイル１３３は、ソースプログラムから分離されたレコード定義用の外部ファイルである。レコード定義ファイル１３３には、ソースプログラム１３１のデータ部と同様に、（従業員コード，Ｘ（５））、（所属コード，Ｘ（３））、（氏名，Ｎ（１０））というレコード定義が記述されている。レコード定義ファイル１３３のレコード定義をソースプログラム１３２のデータ部に取り込むことで、論理ファイル名「人事−ＲＥＣ」が示すファイルのデータにソースプログラム１３２からアクセスすることができる。

レコード定義ファイル１３３はソースプログラム１３２から分離されているため、複数のソースプログラムがレコード定義ファイル１３３を共有することも可能である。なお、上記のＣＯＰＹ文とレコード定義ファイル１３３を利用したレコード定義の方法は、Ｃ言語のｉｎｃｌｕｄｅ文とヘッダファイルを利用することによっても実現できる。

ここで、情報処理システムを長期間運用していると、情報処理システム上で使用されるプログラム資産の拡張や変更が繰り返されることがある。その結果として、同一のファイルに対して、図３のような埋め込み形式のレコード定義を利用するソースプログラムと図４のような外部参照形式のレコード定義を利用するソースプログラムとが、プログラム資産の中に混在することがある。また、レコード定義の記述方法が統一されず、ソースプログラムやレコード定義ファイルによってレコード定義が異なることがある。

同一のファイルに対して異なるレコード定義が存在する原因として、例えば、不注意により既存のデータ項目名と異なるデータ項目名を使用して新しいソースプログラムを作成してしまったことが考えられる。この場合、事後的にデータ項目名を統一することが可能であることが多い。一方、原因として、例えば、処理ロジックを記述する都合上、既存のソースプログラムが使用していない新たな集団項目名を定義した場合や、意図的に既存のレコード定義とは異なるデータ型を使用した場合も考えられる。この場合、処理ロジックが変わらないようにレコード定義を事後的に統一することが難しいことがある。

同一のファイルについてのレコード定義が様々なソースプログラムに重複して記述されている場合、プログラム資産の保守性が低下して以降の保守コストが増大する。また、同一のファイルについて複数のタイプのレコード定義が存在する場合にも、プログラム資産の保守性が低下して以降の保守コストが増大する。そこで、理想的には、１つのファイルについて１つのレコード定義ファイルを作成し、当該ファイルにアクセスするソースプログラムは全て当該レコード定義ファイルを参照するようにすることが好ましい。

ただし、上記のように、同一のファイルについてのレコード定義を機械的に統一することが難しい場合がある。そこで、プログラム資産の保守性を向上させるために、情報処理システムのユーザやエンジニアなどがソースプログラムを見直し、統一することが可能な範囲でレコード定義を修正することがある。第２の実施の形態のプログラム分析装置１００は、そのようなレコード定義の修正作業を支援する。具体的には、プログラム分析装置１００は、複数のタイプのレコード定義の使用状況を可視化する。

以下、プログラム分析装置１００による可視化方法を説明する。まず、ソースプログラムからアクセスされるファイルの物理的同一性を判定する方法について説明する。
図５は、ＪＣＬファイルの例を示す図である。

ＪＣＬファイル１３４は、１以上のソースプログラムを所定の順序で起動させるジョブを制御するためのＪＣＬプログラムを記述したバッチファイルである。ＪＣＬファイル１３４のファイル名は「ＪＣＬ０１」である。プログラム分析装置１００は、ＪＣＬファイル１３４を用いて、論理ファイル名から実ファイル名を特定する。

ＪＣＬファイル１３４には、複数のジョブステップが定義される。各ジョブステップについて、ＪＣＬファイル１３４には、ジョブ名と、起動されるソースプログラムのプログラム名が記述される。図５のＪＣＬファイル１３４には、ジョブ名「ＪＯＢ１」とプログラム名「ＰＲＯＧＲＡＭ１」が記述されている。また、各ジョブステップについて、ＪＣＬファイル１３４には、中間ファイル名と実ファイル名との対応関係が記述される。図５のＪＣＬファイル１３４には、中間ファイル名「ＦＩＬＥ１」が実ファイル名「ＦＩＬＥ１．ＤＡＴ１」に対応することが記述されている。同様に、中間ファイル名「ＦＩＬＥ２」が実ファイル名「ＦＩＬＥ２．ＤＡＴ２」に対応し、中間ファイル名「ＦＩＬＥ３」が実ファイル名「ＦＩＬＥ３．ＤＡＴ３」に対応することが記述されている。

なお、ＪＣＬファイル１３４には、データの使用方法を示すパラメータが記述されることがある。「ＮＥＷ」はそのジョブステップでデータを新規に生成することを示す。「ＯＬＤ」はそのジョブステップの前から存在するデータを排他的に読み出すことを示す。「ＳＨＲ」はそのジョブステップの前から存在するデータを共有で読み出すことを示す。

図６は、ファイル参照テーブルの例を示す図である。
プログラム分析装置１００は、１以上のソースプログラムと１以上のＪＣＬファイルとを分析してファイル参照テーブル１３５を生成する。ファイル参照テーブル１３５は、プログラム名、中間ファイル名、論理ファイル名、レコード定義ファイル名、ＪＣＬファイル名、ジョブ名および実ファイル名の項目を有する。

プログラム名の項目には、ソースプログラムやＪＣＬファイルから抽出されたプログラム名が登録される。中間ファイル名の項目には、ソースプログラムやＪＣＬファイルから抽出された中間ファイル名が登録される。論理ファイル名の項目には、ソースプログラムから抽出された論理ファイル名が登録される。レコード定義ファイル名の項目には、ソースプログラムから抽出されたレコード定義ファイル名が登録される。ただし、レコード定義が直接埋め込まれているソースコードについては、レコード定義ファイル名の項目は空欄となる。ＪＣＬファイル名の項目には、ＪＣＬファイルのファイル名が登録される。ジョブ名の項目には、ＪＣＬファイルから抽出されたジョブ名が登録される。実ファイル名の項目には、ＪＣＬファイルから抽出された実ファイル名が登録される。

プログラム分析装置１００は、１以上のソースプログラムそれぞれについて、見出し部からプログラム名を抽出し、環境部から中間ファイル名と論理ファイル名を抽出する。また、プログラム分析装置１００は、抽出した論理ファイル名についてのＣＯＰＹ文がデータ部に記述されている場合、ＣＯＰＹ文に含まれるレコード定義ファイル名を抽出する。プログラム分析装置１００は、抽出したプログラム名と中間ファイル名と論理ファイル名とレコード定義ファイル名を対応付けてファイル参照テーブル１３５に登録する。

例えば、プログラム分析装置１００は、ソースプログラム１３１から、プログラム名「ＰＲＯＧＲＡＭ１」、中間ファイル名「ＦＩＬＥ１」および論理ファイル名「人事−ＲＥＣ」を抽出して登録する。レコード定義がソースプログラム１３１に直接埋め込まれているため、レコード定義ファイル名の項目は空欄になる。また、例えば、プログラム分析装置１００は、ソースプログラム１３２から、プログラム名「ＰＲＯＧＲＡＭ２」、中間ファイル名「ＦＩＬＥ１」、論理ファイル名「人事−ＲＥＣ」およびレコード定義ファイル名「人事ＲＥＣファイル」を抽出して登録する。

また、プログラム分析装置１００は、１以上のＪＣＬファイルそれぞれについて、ＪＣＬファイル名、ジョブ名、プログラム名、中間ファイル名および実ファイル名を抽出する。プログラム分析装置１００は、ファイル参照テーブル１３５から、抽出したプログラム名と中間ファイル名を含む情報を検索し、検索した情報と対応付けて、抽出したＪＣＬファイル名とジョブ名と実ファイル名をファイル参照テーブル１３５に登録する。

例えば、プログラム分析装置１００は、ＪＣＬファイル１３４から、ＪＣＬファイル名「ＪＣＬ０１」、ジョブ名「ＪＯＢ１」、プログラム名「ＰＲＯＧＲＡＭ１」、中間ファイル名「ＦＩＬＥ１」および実ファイル名「ＦＩＬＥ１．ＤＡＴ１」を抽出する。プログラム分析装置１００は、ファイル参照テーブル１３５から、プログラム名「ＰＲＯＧＲＡＭ１」と中間ファイル名「ＦＩＬＥ１」に対応する行を検索する。プログラム分析装置１００は、ファイル参照テーブル１３５の検索した行に、ＪＣＬファイル名「ＪＣＬ０１」、ジョブ名「ＪＯＢ１」および実ファイル名「ＦＩＬＥ１．ＤＡＴ１」を登録する。

これにより、プログラム名とレコード定義ファイル名と実ファイル名を紐付けることができる。すなわち、複数のソースプログラムそれぞれがデータアクセスに用いる物理的なファイルと、参照するレコード定義ファイルとを特定できる。

次に、プログラム資産に含まれるレコード定義のタイプ分類について説明する。
図７は、レコード定義のタイプ分類例を示す図である。
レコード定義１４１〜１４５は、同一のファイルについての異なるレコード定義であり、例えば、異なるソースプログラムに記述されたものである。

レコード定義１４１に記述された「ＸＸＸ−ＫＥＹ」、「ＸＸＸ−ＦＬＧ」は集団項目名である。レコード定義１４１に記述された「ＸＸＸ−ＰＧＭ−ＩＤ」、「ＸＸＸ−ＳＥＱ−ＮＯ」、「ＸＸＸ−ＴＡＮＭＡＴＳＵ−ＫＢＮ」はデータ項目名である。また、レコード定義１４１に記述された「ＸＸＸ−ＦＬＧ−１」、「ＸＸＸ−ＦＬＧ−２」、「ＸＸＸ−ＦＬＧ−３」、「ＸＸＸ−ＦＬＧ−４」、「ＸＸＸ−ＦＬＧ−５」はデータ項目名である。また、レコード定義１４１に記述された「ＸＸＸ−ＳＩＴＥ−ＭＥＩ」、「ＸＸＸ−ＳＩＴＥ−ＭＥＩ−ＲＹＡＫＵＳＨＯ」、「ＦＩＬＬＥＲ」はデータ項目名である。レコード定義１４１に記述された「Ｘ（０７）」、「９（０２）」、「Ｘ（０１）」、「Ｎ（１５）」、「Ｎ（０７）」、「Ｘ（２１）」はデータ型である。

データ項目名に含まれる「ＸＸＸ−」は接頭辞である。２つのデータ項目名の同一性を判断するにあたり、プログラム分析装置１００は、接頭辞を匿名化する（接頭辞の違いを無視する）ことがある。データ項目名の接頭辞は論理ファイル名と関連していることがある。例えば、論理ファイル名が「Ｕ０１−ＲＥＣ」であるファイルについてのデータ項目名が「Ｕ０１−ＡＡＡ」のように定義されることがある。この場合、データ項目名の先頭に付加されている「Ｕ０１−」を接頭辞とみなすことができる。

レコード定義１４２は、データ項目名「ＸＸＸ−ＳＩＴＥ−ＭＥＩ」に対応するデータ型が「Ｘ（３０）」である点でレコード定義１４１と異なる。また、レコード定義１４２は、データ項目名「ＸＸＸ−ＳＩＴＥ−ＭＥＩ−ＲＹＡＫＵＳＨＯ」に対応するデータ型が「Ｘ（１４）」である点でレコード定義１４１と異なる。よって、レコード定義１４１が第１のタイプに属するとすると、レコード定義１４２は第２のタイプに属する。

レコード定義１４３は、「ＸＸＸ−ＳＩＴＥ−ＭＥＩ−ＲＹＡＫＵＳＨＯ」が集団項目名であり、「ＸＸＸ−ＳＩＴＥ−ＭＥＩ−ＲＹＡＫＵ−ＫＪ」がデータ項目名である点でレコード定義１４１と異なる。レコード定義１４３は、レコード定義１４１，１４２の何れとも異なっている。よって、レコード定義１４３は第３のタイプに属する。

図８は、レコード定義のタイプ分類例を示す図（続き）である。
レコード定義１４４は、レコード定義１４１のデータ項目名「ＸＸＸ−ＦＬＧ」が「ＸＸＸ−ＳＨＯＲＩ−ＦＬＧ」に変更されている点でレコード定義１４１と異なる。また、レコード定義１４４は、レコード定義１４１のデータ項目名「ＦＩＬＬＥＲ」が「ＸＸＸ−ＦＩＬＬＥＲ」に変更されている点でレコード定義１４１と異なる。レコード定義１４４は、レコード定義１４１〜１４３の何れとも異なっている。よって、レコード定義１４４は第４のタイプに属する。なお、接頭辞を匿名化する場合、「ＦＩＬＬＥＲ」と「ＸＸＸ−ＦＩＬＬＥＲ」とが実質的に同じであると判断されてもよい。

レコード定義１４５は、データ項目名「ＸＸＸ−ＳＩＴＥ−ＭＥＩ」に対応するデータ型が「Ｘ（３０）」である点でレコード定義１４１と異なる。また、レコード定義１４５は、データ項目名「ＸＸＸ−ＳＩＴＥ−ＭＥＩ−ＲＹＡＫＵＳＨＯ」に対応するデータ型が「Ｘ（１４）」である点でレコード定義１４１と異なる。また、レコード定義１４５は、レコード定義１４１のデータ項目名「ＦＩＬＬＥＲ」が「ＸＸＸ−ＦＩＬＬＥＲ」に変更されている点でレコード定義１４１と異なる。上記のデータ型の差異は、レコード定義１４２と同様である。また、上記のデータ項目名の差異は、レコード定義１４４と同様である。しかし、レコード定義１４５は、全体としてレコード定義１４１〜１４４の何れとも異なっている。よって、レコード定義１４５は第５のタイプに属する。このように、レコード定義１４１〜１４５は互いに異なるタイプに属することになる。

図９は、タイプ分類テーブルの例を示す図である。
プログラム分析装置１００は、上記のようにして分類した複数のタイプの使用状況を可視化するにあたり、タイプ分類テーブル１３６を生成する。

プログラム分析装置１００は、レコード定義のタイプ毎に、当該タイプに属するレコード定義を使用するソースプログラムの数をカウントする。複数のソースプログラムが共通のレコード定義ファイルをＣＯＰＹ文によって参照している場合、ＣＯＰＹ文１つにつきカウントが＋１される。また、プログラム分析装置１００は、タイプ毎に共通のレコード定義ファイルを作成してソースプログラムに直接記述されたレコード定義を全て外部参照形式に変換した場合の削減率を試算する。削減率は、現在のプログラム資産に含まれるソースプログラムの総ステップ数（例えば、総行数）に対する、変換により減少するソースプログラムのステップ数（例えば、減少行数）の割合である。

削減率は実ファイル毎に算出される。多数のソースプログラムに埋め込み形式で記述されているタイプが存在する実ファイルは、削減率が大きくなりやすい。一方、既に１つまたは少数のレコード定義ファイルを参照する外部参照形式に統一されているタイプが存在する実ファイルは、削減率が小さくなりやすい。また、少数のソースプログラムでしか使用されていないタイプが存在する実ファイルは、削減率が小さくなりやすい。

ここで、接頭辞を匿名化してデータ項目名同士を比較した場合（接頭辞を無視した場合）、接頭辞を無視しない場合よりもタイプ数が少なくなる。この場合、接頭辞のみ異なるレコード定義の記述を統一することができれば、接頭辞を無視しない場合よりも削減率が大きくなる。そこで、プログラム分析装置１００は、接頭辞を無視しない場合と接頭辞を無視した場合の両方についてプログラム数や削減率を算出することが好ましい。

タイプ分類テーブル１３６は、実ファイル名、プログラム数、削減率、接頭辞無視のプログラム数および接頭辞無視の削減率の項目を有する。実ファイル名の項目には、ソースプログラムからアクセスされる物理的なファイルの実ファイル名が登録される。プログラム数の項目には、接頭辞を無視せずにレコード定義をタイプ分類したときの複数のタイプのソースプログラム数が列挙される。実ファイル名とプログラム名の関係は、ファイル参照テーブル１３５を用いて特定することができる。

削減率の項目には、接頭辞を無視しないことで得られた複数のタイプそれぞれを外部参照形式に変換した場合の削減率が登録される。接頭辞無視のプログラム数の項目には、接頭辞を無視してレコード定義をタイプ分類したときの複数のタイプのソースプログラム数が列挙される。接頭辞を無視したときのタイプ数は、接頭辞を無視しないときのタイプ数以下となる。接頭辞無視の削減率の項目には、接頭辞を無視することで得られた複数のタイプそれぞれを外部参照形式に変換した場合の削減率が登録される。接頭辞を無視したときの削減率は、接頭辞を無視しないときの削減率以上となる。

プログラム分析装置１００は、生成したタイプ分類テーブル１３６に基づいて可視化画面をディスプレイ１１１に表示する。次に、可視化画面の例を説明する。
図１０は、レコード定義分布の第１の可視化例を示す図である。

可視化画面１５１はディスプレイ１１１に表示される。可視化画面１５１は、実ファイル名が「ファイルＡ」であるファイルについての複数のタイプの使用状況を示す。可視化画面１５１の左側の円グラフは、接頭辞を無視しない場合の複数のタイプの間のプログラム数の比を示している。可視化画面１５１の右側の円グラフは、接頭辞を無視した場合の複数のタイプの間のプログラム数の比を示している。

円グラフを用いることで、あるファイルについて最も多く使用されているレコード定義のタイプを把握することが容易となる。ユーザは、例えば、最も多く使用されているタイプを標準レコード定義として選択し、当該ファイルのレコード定義を標準レコード定義に統一することを検討することが考えられる。また、円グラフを用いることで、標準レコード定義以外のタイプがどの程度使用されているか把握することが容易となる。これにより、ユーザは、例えば、当該ファイルのレコード定義を修正することによるプログラム資産の保守性向上効果を見積もることが可能となる。プログラム分析装置１００は、ユーザ入力に応じて、異なるファイルについての円グラフを表示してもよい。

図１１は、レコード定義分布の第２の可視化例を示す図である。
可視化画面１５２はディスプレイ１１１に表示される。可視化画面１５２は、複数のファイルについての複数のタイプの使用状況を示す。可視化画面１５２では、各ファイルについての複数のタイプのプログラム数が積み上げ棒グラフによって表されている。図１１の例は、接頭辞を無視した場合のプログラム数を示す。プログラム分析装置１００は、ユーザ入力に応じて、接頭辞を無視した場合のグラフと無視しない場合のグラフを切り替えて表示してもよい。積み上げ棒グラフを用いることで、図１０の場合と同様に、あるファイルについて最も多く使用されているレコード定義のタイプを把握することが容易となる。また、積み上げ棒グラフを用いることで、標準レコード定義以外のタイプがどの程度使用されているか把握することが容易となる。

図１２は、プログラム修正効果の可視化例を示す図である。
可視化画面１５３はディスプレイ１１１に表示される。可視化画面１５３は、複数の実ファイル名それぞれについて、接頭辞を無視せずに試算した削減率と接頭辞を無視して試算した削減率とを表形式で表している。可視化画面１５３によれば、ソースプログラムのレコード定義を外部参照形式に変換することによる効果を定量的に表現できる。図１２では、削減率が１％以上になる場合を強調表示している。

次に、プログラム分析装置１００の機能について説明する。
図１３は、プログラム分析装置の機能例を示すブロック図である。
プログラム分析装置１００は、ＪＣＬファイル記憶部１２１、ソースプログラム記憶部１２２、ファイル参照テーブル記憶部１２３およびタイプ分類テーブル記憶部１２４を有する。また、プログラム分析装置１００は、ＪＣＬファイル分析部１２５、ソースプログラム分析部１２６、タイプ判定部１２７および表示制御部１２８を有する。

ＪＣＬファイル記憶部１２１、ソースプログラム記憶部１２２、ファイル参照テーブル記憶部１２３およびタイプ分類テーブル記憶部１２４は、例えば、ＲＡＭ１０２またはＨＤＤ１０３の記憶領域を用いて実装される。ＪＣＬファイル分析部１２５、ソースプログラム分析部１２６、タイプ判定部１２７および表示制御部１２８は、例えば、ＣＰＵ１０１が実行するプログラムモジュールを用いて実装される。

ＪＣＬファイル記憶部１２１は、ＪＣＬファイル１３４のような１以上のＪＣＬファイルを記憶する。プログラム分析装置１００は、ＪＣＬファイル記憶部１２１に記憶されるＪＣＬファイルを他の装置から受信してもよい。また、プログラム分析装置１００は、ＪＣＬファイルを記録媒体１１３から読み出してもよい。

ソースプログラム記憶部１２２は、ソースプログラム１３１，１３２のような１以上のソースプログラムを記憶する。また、ソースプログラム記憶部１２２は、ソースプログラムから参照される１以上のレコード定義ファイルを記憶する。プログラム分析装置１００は、ソースプログラム記憶部１２２に記憶されるソースプログラムやレコード定義ファイルを他の装置から受信してもよい。また、プログラム分析装置１００は、ソースプログラムやレコード定義ファイルを記録媒体１１３から読み出してもよい。

ファイル参照テーブル記憶部１２３は、ファイル参照テーブル１３５を記憶する。タイプ分類テーブル記憶部１２４は、タイプ分類テーブル１３６を記憶する。
ＪＣＬファイル分析部１２５は、ＪＣＬファイル記憶部１２１に記憶されたＪＣＬファイルを分析し、ＪＣＬファイル名、ジョブ名、プログラム名、中間ファイル名および実ファイル名を抽出する。ＪＣＬファイル分析部１２５は、ファイル参照テーブル記憶部１２３に記憶されたファイル参照テーブル１３５に、プログラム名および中間ファイル名と対応付けて、ＪＣＬファイル名、ジョブ名および実ファイル名を登録する。

ソースプログラム分析部１２６は、ソースプログラム記憶部１２２に記憶されたソースプログラムを分析し、プログラム名、中間ファイル名、論理ファイル名およびレコード定義ファイル名を抽出する。ソースプログラム分析部１２６は、ファイル参照テーブル記憶部１２３に記憶されたファイル参照テーブル１３５に、プログラム名、中間ファイル名、論理ファイル名およびレコード定義ファイル名を登録する。

タイプ判定部１２７は、ファイル参照テーブル記憶部１２３に記憶されたファイル参照テーブル１３５を参照して、ソースプログラム記憶部１２２に記憶されたソースプログラムやレコード定義ファイルからレコード定義を抽出する。タイプ判定部１２７は、同一のファイルに対するレコード定義を相互に比較して複数のタイプに分類する。

タイプ判定部１２７は、接頭辞を無視しない場合と接頭辞を無視した場合それぞれについて、複数のタイプそれぞれに属するレコード定義を使用するソースプログラムの数をカウントする。タイプ判定部１２７は、タイプ分類テーブル記憶部１２４に記憶されたタイプ分類テーブル１３６に、接頭辞を無視しない場合のプログラム数と接頭辞を無視した場合のプログラム数を登録する。また、タイプ判定部１２７は、タイプ毎に１つのレコード定義ファイルを生成するシミュレーションを行い、接頭辞を無視しない場合と接頭辞を無視した場合それぞれについて削減率を試算する。タイプ判定部１２７は、タイプ分類テーブル記憶部１２４に記憶されたタイプ分類テーブル１３６に、接頭辞を無視しない場合の削減率と接頭辞を無視した場合の削減率を登録する。

表示制御部１２８は、タイプ分類テーブル記憶部１２４に記憶されたタイプ分類テーブル１３６に基づいて、可視化画面１５１〜１５３のような可視化画面を生成する。表示制御部１２８は、生成した可視化画面をディスプレイ１１１に表示させる。表示制御部１２８は、ユーザからの入力に応じて、表示する可視化画面を切り替えてもよい。なお、プログラム分析装置１００は、タイプ分類テーブル１３６の情報またはそれに基づいて生成された可視化情報（グラフなど）を他の装置に送信してもよい。また、プログラム分析装置１００は、タイプ分類テーブル１３６の情報またはそれに基づいて生成された可視化情報を、ディスプレイ１１１以外の出力デバイス（プリンタなど）に出力してもよい。

図１４は、プログラム分析の手順例を示すフローチャートである。
（Ｓ１０）ソースプログラム分析部１２６は、ソースプログラムを１つ選択する。
（Ｓ１１）ソースプログラム分析部１２６は、選択したソースプログラムの見出し部からプログラム名を抽出する。また、ソースプログラム分析部１２６は、選択したソースプログラムの環境部から中間ファイル名と論理ファイル名を抽出する。

（Ｓ１２）ソースプログラム分析部１２６は、選択したソースプログラムのデータ部から、ステップＳ１１で抽出した論理ファイル名についての記述を取得する。そして、ソースプログラム分析部１２６は、当該論理ファイル名についての記述が、当該ソースプログラム外のレコード定義ファイルを参照するものであるか、すなわち、レコード定義を取り込むＣＯＰＹ文であるか判断する。ＣＯＰＹ文である場合はステップＳ１３に処理が進み、ＣＯＰＹ文でない場合はステップＳ１４に処理が進む。

（Ｓ１３）ソースプログラム分析部１２６は、選択したソースプログラムのデータ部から、論理ファイル名と当該論理ファイル名に対応付けられたレコード定義ファイル名を抽出する。そして、ステップＳ１５に処理が進む。

（Ｓ１４）ソースプログラム分析部１２６は、選択したソースプログラムのデータ部から論理ファイル名を抽出する。そして、ステップＳ１５に処理が進む。
（Ｓ１５）ソースプログラム分析部１２６は、ファイル参照テーブル１３５に、抽出したプログラム名、中間ファイル名、論理ファイル名およびレコード定義ファイル名を対応付けて登録する。ただし、レコード定義ファイル名が抽出されなかった場合（ステップＳ１３を実行しなかった場合）には、レコード定義ファイル名の項目は空欄となる。

（Ｓ１６）ソースプログラム分析部１２６は、未選択の残りのソースプログラムが存在するか判断する。残りのソースプログラムがある場合はステップＳ１０に処理が進み、残りのソースプログラムがない場合はステップＳ１７に処理が進む。

（Ｓ１７）ＪＣＬファイル分析部１２５は、ＪＣＬファイルに記述されたジョブステップを１つ選択する。１つのジョブステップは、１つのソースプログラムの実行を示す。
（Ｓ１８）ＪＣＬファイル分析部１２５は、選択したジョブステップが記述されたＪＣＬファイルのＪＣＬファイル名を取得する。また、ＪＣＬファイル分析部１２５は、選択したジョブステップの記述から、ジョブ名、起動するソースプログラムのプログラム名、使用するファイルの１以上の中間ファイル名および１以上の実ファイル名を抽出する。

（Ｓ１９）ＪＣＬファイル分析部１２５は、ステップＳ１８で抽出したプログラム名と中間ファイル名の組が、ファイル参照テーブル１３５に登録されているか判断する。プログラム名と中間ファイル名の組が登録されている場合はステップＳ２０に処理が進み、登録されていない場合はステップＳ２１に処理が進む。

（Ｓ２０）ＪＣＬファイル分析部１２５は、抽出したプログラム名および中間ファイル名と対応付けて、ステップＳ１８で抽出したＪＣＬファイル名、ジョブ名および実ファイル名をファイル参照テーブル１３５に登録する。

（Ｓ２１）ＪＣＬファイル分析部１２５は、未選択の残りのジョブステップが存在するか判断する。残りのジョブステップがある場合はステップＳ１７に処理が進み、残りのジョブステップがない場合はステップＳ２２に処理が進む。

図１５は、プログラム分析の手順例を示すフローチャート（続き）である。
（Ｓ２２）タイプ判定部１２７は、ファイル参照テーブル１３５に登録された情報を実ファイル名でソートし、同じ実ファイル名の情報を纏める。

（Ｓ２３）タイプ判定部１２７は、実ファイル名を１つ選択する。
（Ｓ２４）タイプ判定部１２７は、選択した実ファイル名が示すファイルについてのレコード定義を、ソースプログラム記憶部１２２に記憶されたソースプログラムやレコード定義ファイルから全て抽出する。すなわち、タイプ判定部１２７は、ファイル参照テーブル１３５から、選択した実ファイル名を含む情報を抽出する。タイプ判定部１２７は、レコード定義ファイル名が登録されていない情報に対しては、ソースプログラムからレコード定義を抽出する。一方、タイプ判定部１２７は、レコード定義ファイル名が登録されている情報に対しては、レコード定義ファイルからレコード定義を抽出する。

（Ｓ２５）タイプ判定部１２７は、ステップＳ２４で抽出した複数のレコード定義を比較して、それら複数のレコード定義を複数のタイプに分類する。ここでは、タイプ判定部１２７は、データ項目名の接頭辞を匿名化せずにレコード定義を比較する。よって、同じタイプに属するレコード定義は、データ項目名とデータ型が完全に一致している。

（Ｓ２６）タイプ判定部１２７は、ステップＳ２５で得られた複数のタイプそれぞれについて、当該タイプに属するレコード定義を使用するソースプログラムの数をカウントする。埋め込み形式のソースプログラムについては、当該タイプに属するレコード定義がデータ部に記述されているソースプログラム１つにつき、カウントが＋１される。外部参照形式のソースプログラムについては、当該タイプに属するレコード定義を記述したレコード定義ファイルを参照するソースプログラム１つにつき、カウントが＋１される。タイプ判定部１２７は、複数のタイプのプログラム数をタイプ分類テーブル１３６に登録する。

（Ｓ２７）タイプ判定部１２７は、現在のプログラム資産に含まれるソースプログラムおよびレコード定義ファイルの総行数を算出する。
（Ｓ２８）タイプ判定部１２７は、タイプ毎にレコード定義を外部化すること、すなわち、タイプ毎に１つのレコード定義ファイルを生成して全てのソースプログラムを外部参照形式に変換するシミュレーションを行う。そして、タイプ判定部１２７は、レコード定義の外部化により減少する行数を試算する。なお、レコード定義の外部化によりソースプログラムの行数が減少する一方、新たに生成したレコード定義ファイルの行数だけ増加することがある。ここで試算される行数は、両者の差分である実質的な減少行数である。

（Ｓ２９）タイプ判定部１２７は、ステップＳ２８で試算した減少行数をステップＳ２７で算出した総行数で割った削減率を算出する。タイプ判定部１２７は、選択した実ファイル名と対応付けて、算出した削減率をタイプ分類テーブル１３６に登録する。

（Ｓ３０）タイプ判定部１２７は、ステップＳ２４で抽出したレコード定義に含まれるデータ項目名から接頭辞の部分を判断し、接頭辞を匿名化する。タイプ判定部１２７は、データ項目名に含まれる接頭辞を特殊な文字または文字列に置換してもよい。また、タイプ判定部１２７は、データ項目名から接頭辞を削除してもよい。

（Ｓ３１）タイプ判定部１２７は、ステップＳ３０で接頭辞を匿名化したレコード定義を用いて、ステップＳ２５〜Ｓ２９と同様の処理を行う。これにより、接頭辞の違いを無視した場合の複数のタイプが得られ、複数のタイプそれぞれのプログラム数が算出される。また、接頭辞の違いを無視した場合の削減率が算出される。タイプ判定部１２７は、算出したプログラム数と削減率をタイプ分類テーブル１３６に登録する。

（Ｓ３２）タイプ判定部１２７は、未選択の残りの実ファイル名が存在するか判断する。残りの実ファイル名がある場合はステップＳ２３に処理が進み、残りの実ファイル名がない場合はステップＳ３３に処理が進む。

（Ｓ３３）表示制御部１２８は、タイプ分類テーブル１３６に基づいて可視化画面を生成し、ディスプレイ１１１に可視化画面を表示させる。例えば、表示制御部１２８は、１以上の実ファイル名について、複数のタイプの間のプログラム数の比を算出し、可視化画面１５１のような円グラフを表示させる。また、例えば、表示制御部１２８は、１以上の実ファイル名について、可視化画面１５２のような積み上げ棒グラフを表示させる。また、例えば、表示制御部１２８は、可視化画面１５３のような削減率を表示させる。

第２の実施の形態のプログラム分析装置１００によれば、ソースプログラムとＪＣＬファイルを分析することで、データが格納された物理的なファイルとソースプログラムとが紐付けられる。この紐付けに基づいて、同一のファイルに対する複数のレコード定義が抽出され、複数のレコード定義の間の比較に基づいてそれら複数のレコード定義が複数のタイプに分類される。そして、複数のタイプそれぞれについてソースプログラムの数がカウントされ、複数のタイプの間のプログラム数の分布が表示される。

これにより、同一のファイルに対する複数のレコード定義の使用状況を可視化することができる。よって、レコード定義の記述方法を統一する修正作業や、レコード定義の記述をソースプログラムからレコード定義ファイルに移動する修正作業を効率化できる。例えば、レコード定義で使用するデータ項目名を統一するにあたり、複数のタイプのうち最もプログラム数の多いタイプのデータ項目名を標準データ項目名として選択することで、修正作業を効率化することができる。また、例えば、プログラム数の多いタイプのレコード定義を修正対象として優先的に検討することで、限られた時間の中で保守性改善効果の大きい修正作業を優先的に行うことが可能となる。また、削減率の大きいファイルについて優先的に修正作業を行うことで、大きな保守性改善効果を得ることができる。

１０ プログラム分析装置
１１ 記憶部
１２ 演算部
１３ プログラム資産
１４ａ，１４ｂ，１４ｃ，１４ｄ，１４ｅ，１４ｆ データ構造定義文
１５ａ，１５ｂ，１５ｃ タイプ
１６ 分布情報

Claims (6)

1. コンピュータが実行するプログラム分析方法であって、
   同一のファイルにアクセスする複数のプログラムを含むプログラム資産から、それぞれが前記ファイルに格納されるデータの構造を示す複数のデータ構造定義文を抽出し、
   前記複数のデータ構造定義文の間の比較に基づいて前記複数のデータ構造定義文を複数のタイプに分類し、前記複数のタイプそれぞれについて前記複数のプログラムのうち当該タイプに属するデータ構造定義文を使用するプログラムの数をカウントし、
   前記複数のタイプの間の前記プログラムの数の分布を示す分布情報を出力する、
   プログラム分析方法。
2. 前記複数のデータ構造定義文それぞれは、前記ファイルに格納されるデータに含まれる１以上のデータ項目に対応する１以上のデータ型を示し、
   異なるデータ型を使用するデータ構造定義文は異なるタイプに分類される、
   請求項１記載のプログラム分析方法。
3. 前記分布情報は、前記複数のタイプそれぞれの前記プログラムの数を示す第１のグラフ、および、前記複数のタイプの間の前記プログラムの数の比を示す第２のグラフの少なくとも一方を含む、
   請求項１記載のプログラム分析方法。
4. 更に、タイプ毎に当該タイプに属するデータ構造定義文を前記複数のプログラムから分離して共通ファイルに集約した場合に生じる前記プログラム資産の規模の変化を算出し、前記規模の変化を示す修正効果情報を出力する、
   請求項１記載のプログラム分析方法。
5. 同一のファイルにアクセスする複数のプログラムを含むプログラム資産を記憶する記憶部と、
   前記プログラム資産からそれぞれが前記ファイルに格納されるデータの構造を示す複数のデータ構造定義文を抽出し、前記複数のデータ構造定義文の間の比較に基づいて前記複数のデータ構造定義文を複数のタイプに分類し、前記複数のタイプそれぞれについて前記複数のプログラムのうち当該タイプに属するデータ構造定義文を使用するプログラムの数をカウントし、前記複数のタイプの間の前記プログラムの数の分布を示す分布情報を出力する演算部と、
   を有するプログラム分析装置。
6. コンピュータに、
   同一のファイルにアクセスする複数のプログラムを含むプログラム資産から、それぞれが前記ファイルに格納されるデータの構造を示す複数のデータ構造定義文を抽出し、
   前記複数のデータ構造定義文の間の比較に基づいて前記複数のデータ構造定義文を複数のタイプに分類し、前記複数のタイプそれぞれについて前記複数のプログラムのうち当該タイプに属するデータ構造定義文を使用するプログラムの数をカウントし、
   前記複数のタイプの間の前記プログラムの数の分布を示す分布情報を出力する、
   処理を実行させる分析プログラム。

Images