(57)【要約】      （修正有）【課題】既存のシステムのソフトウェア構造をより保守性の高いシステムのソフトウェア構造に変更する。【解決手段】サーバ装置（ソフトウェア構造変更支援装置）と端末装置がネットワークで接続される。サーバ装置は、ソフトウェアのソースコードにおけるプログラム間の呼び出し関係と、プログラムとデータとの関係性を解析し、プログラムをノードとして定義し、呼び出し関係を方向付きエッジとして定義してソフトウェアの構造を解析するソフトウェア構造解析手段１０１１と、解析されたソフトウェアの構造と保守履歴とに基づいて、方向付きエッジの関係性に重みとして評価値を付与する評価値算出手段１０１２と、付与した評価値に基づいてノードを分割してモジュールを作成するモジュール分割手段１０２１と、を有する。端末装置は、解析されたソフトウェアの構造をグラフとして表示し、作成されたモジュールの境界をグラフに付加して表示する。【選択図】図２
2018151713.tif 000002
【特許請求の範囲】
【請求項１】
サーバ装置と、所定の入力を受け及び情報を表示する端末装置とがネットワークで接続されたソフトウェア構造変更支援システムであって、
前記サーバ装置は、
ソフトウェアのソースコードにおける複数のプログラムの間の呼び出し関係と、前記複数のプログラムと複数のデータとの関係性を解析し、前記複数のプログラムを複数のノードとして定義し、前記複数のプログラムの呼び出し関係を複数の方向付きエッジとして定義して前記ソフトウェアの構造を解析するソフトウェア構造解析手段と、
前記ソフトウェア構造解析手段により解析された前記ソフトウェアの構造と前記ソフトウェアの保守履歴とに基づいて、前記方向付きエッジの関係性に重みとして評価値を付与する評価値算出手段と、
前記評価値算出手段により付与した前記評価値に基づいて、前記複数のノードを分割して所定の機能を実現するためのプログラムの集まりであるモジュールを作成するモジュール分割手段と、を有し、
前記端末装置は、
前記ソフトウェア構造解析手段により解析された前記ソフトウェアの構造をグラフとして表示し、前記モジュール分割手段により作成されたモジュールの境界を前記グラフに付加して表示することを特徴とするソフトウェア構造変更支援システム。
【請求項２】
前記評価値算出手段は、前記ノードについて前記保守履歴を取得し、前記ノードの関係性と前記保守履歴にそれぞれ前記評価値を付与し、前記評価値に基づいて前記エッジの重みを算出することを特徴とする請求項１に記載のソフトウェア構造変更支援システム。
【請求項３】
前記保守履歴として前記プログラムの利用実績データを格納する実績データテーブルを有し、
前記評価値算出手段は、前記実績データテーブルに格納された利用実績データを用いて前記評価値を付与することを特徴とする請求項１に記載のソフトウェア構造変更支援システム。
【請求項４】
前記実績データテーブルは、前記利用実績データとして、前記プログラムのバグの発生数を格納することを特徴とする請求項３に記載のソフトウェア構造変更支援システム。
【請求項５】
前記モジュール分割手段は、前記表示手段で受け付けたモジュール分割数に達するまで最小カットを実施して前記複数のノードを分割することを特徴とする請求項１に記載のソフトウェア構造変更支援システム。
【請求項６】
前記端末装置は、前記保守履歴に基づいて、前記ノード及び前記方向付きエッジの表示態様を変更して表示することを特徴とする請求項１に記載のソフトウェア構造変更支援システム。
【請求項７】
前記端末装置は、前記エッジの重みに応じて、前記エッジの線種又は太さを変更して表示することを特徴とする請求項６に記載のソフトウェア構造変更支援システム。
【請求項８】
サーバ装置と、所定の入力を受け付け及び情報を表示する端末装置とがネットワークで接続されたシステムを用いてソフトウェア構造の変更を支援するソフトウェア構造変更支援方法であって、
前記サーバ装置は、
ソフトウェアのソースコードにおける複数のプログラムの間の呼び出し関係と、前記複数のプログラムと複数のデータとの関係性を解析し、前記複数のプログラムを複数のノードとして定義し、前記複数のプログラムの呼び出し関係を複数の方向付きエッジとして定義して前記ソフトウェアの構造を解析し、
前記解析された前記ソフトウェアの構造と前記ソフトウェアの保守履歴とに基づいて、前記方向付きエッジの関係性に重みとして評価値を付与し、
前記付与した前記評価値に基づいて、前記複数のノードを分割して所定の機能を実現するためのプログラムの集まりであるモジュールを作成し、
前記端末装置は、
前記解析された前記ソフトウェアの構造をグラフとして表示し、前記作成されたモジュールの境界を前記グラフに付加して表示することを特徴とするソフトウェア構造変更支援方法。
【請求項９】
前記端末装置から前記モジュールの分割数を指定し、
前記指定された分割数に応じて、前記モジュールの境界を変更して前記端末装置に表示することを特徴とする請求項８に記載のソフトウェア構造変更支援方法。
【請求項１０】
前記端末装置から前記モジュールの境界を指定し、
前記指定された境界に応じて、前記モジュールの構成を変更して前記端末装置に表示することを特徴とする請求項８に記載のソフトウェア構造変更支援方法。
【請求項１１】
前記端末装置から前記境界を指定された前記モジュールは、バグが発生したプログラムを有するモジュールであることを特徴とする請求項１０に記載のソフトウェア構造変更支援方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェア構造変更支援システム及びソフトウェア構造変更支援方法に関する。
【背景技術】
【０００２】
環境の異なる複数拠点で動作する生産管理システムのような大規模情報システムでは、基本的には同じ業務機能を提供しつつも、拠点の環境や製造対象に合わせたカスタマイズや拠点独自の機能を追加して動作させている。
【０００３】
このような拠点ごとの作りこみが続くと、運用保守も拠点ごとに対策が必要となり、製造対象の変更、拠点の環境変更等のビジネス環境の変化が発生した場合に、拠点ごとにシステムの改修が必要となってしまい工数がかかってしまう。
【０００４】
上記システム改修の方法の一例として、例えば、特許文献１がある。特許文献１は、大規模かつ複雑化されたソフトウェアであっても、ソースコード中の変数依存関係を解析することにより、作業担当者が熟練者でなくても再利用容易なソフトウェア部品を作成する方法が記載されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１２−２０３７７７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、特許文献１の方法は、ソースコードの解析結果から得られた既存の構造を元に再利用容易なソフトウェア部品を作成するものである。この解析結果だけからでは、現行のソフトウェアの維持管理のしやすさを示す保守性や業務利用状況を考慮したソフトウェア部品を作成することは困難である。
【０００７】
このような場合には、実行頻度や実行タイミング等の業務利用方法やバグの発生回数等の稼動実績などの保守履歴に基づいて、既存の大規模なシステムのソフトウェア構造を、より保守性の高いシステムのソフトウェア構造に変更した方が良い場合がある。
【０００８】
本発明の目的は、既存のシステムのソフトウェア構造をより保守性の高いシステムのソフトウェア構造に変更することにある。
【課題を解決するための手段】
【０００９】
本発明の一態様のソフトウェア構造変更支援システムは、サーバ装置と、所定の入力を受け及び情報を表示する端末装置とがネットワークで接続され、前記サーバ装置は、ソフトウェアのソースコードにおける複数のプログラムの間の呼び出し関係と、前記複数のプログラムと複数のデータとの関係性を解析し、前記複数のプログラムを複数のノードとして定義し、前記複数のプログラムの呼び出し関係を複数の方向付きエッジとして定義して前記ソフトウェアの構造を解析するソフトウェア構造解析手段と、前記ソフトウェア構造解析手段により解析された前記ソフトウェアの構造と前記ソフトウェアの保守履歴とに基づいて、前記方向付きエッジの関係性に重みとして評価値を付与する評価値算出手段と、前記評価値算出手段により付与した前記評価値に基づいて、前記複数のノードを分割して所定の機能を実現するためのプログラムの集まりであるモジュールを作成するモジュール分割手段と、を有し、前記端末装置は、前記ソフトウェア構造解析手段により解析された前記ソフトウェアの構造をグラフとして表示し、前記モジュール分割手段により作成されたモジュールの境界を前記グラフに付加して表示することを特徴とする。
【００１０】
本発明の一態様のソフトウェア構造変更支援方法は、サーバ装置と、所定の入力を受け付け及び情報を表示する端末装置とがネットワークで接続されたシステムを用いてソフトウェア構造の変更を支援し、前記サーバ装置は、ソフトウェアのソースコードにおける複数のプログラムの間の呼び出し関係と、前記複数のプログラムと複数のデータとの関係性を解析し、前記複数のプログラムを複数のノードとして定義し、前記複数のプログラムの呼び出し関係を複数の方向付きエッジとして定義して前記ソフトウェアの構造を解析し、前記解析された前記ソフトウェアの構造と前記ソフトウェアの保守履歴とに基づいて、前記方向付きエッジの関係性に重みとして評価値を付与し、前記付与した前記評価値に基づいて、前記複数のノードを分割して所定の機能を実現するためのプログラムの集まりであるモジュールを作成し、前記端末装置は、前記解析された前記ソフトウェアの構造をグラフとして表示し、前記作成されたモジュールの境界を前記グラフに付加して表示することを特徴とする。
【発明の効果】
【００１１】
本発明の一態様によれば、既存のシステムのソフトウェア構造をより保守性の高いシステムのソフトウェア構造に変更することができる。
【図面の簡単な説明】
【００１２】
【図１】ソフトウェア構造変更支援システムの構成を示す図である。
【図２】ソフトウェア構造変更支援装置のソフトウェア構成を示す図である。
【図３】ソフトウェア構造解析部の処理の流れを示す図である。
【図４】サーバ装置のハードウェア構成を示す図である。
【図５Ａ】ノード情報テーブルのデータ構造を示す図である。
【図５Ｂ】エッジ情報テーブルのデータ構造を示す図である。
【図６Ａ】実績テーブルを示す図である。
【図６Ｂ】開発者の属性情報を管理する開発者情報テーブルを示す図である。
【図７】エッジの評価値を管理するエッジ評価データテーブルを示す図である。
【図８】モジュール評価データテーブルを示す図である。
【図９】傾斜データテーブルを示す図である。
【図１０】ソフトウェア構造解析部の動作を示すフローチャートである。
【図１１】ソフトウェア構造解析手段の動作を示すフローチャートである。
【図１２】モジュール境界変更時におけるソフトウェア構造変更支援装置の動作を示すフローチャートである。
【図１３Ａ】表示装置の動作結果を表示する画面例を示したものであり、ソフトウェア構造を示す初期表示画面である。図１３Ｂがモジュール評価部１０２動作後の表示画面である。
【図１３Ｂ】表示装置の動作結果を表示する画面例を示したものであり、モジュール評価部の動作後の表示画面である。
【図１４】図１３においてＰＧ３とＰＧ４のエッジの境界を変更した後、再計算されたモジュール境界を表示する画面例を示した図である。
【図１５】エッジの重み付け方法を示す図である。
【発明を実施するための形態】
【００１３】
以下に、図面を参照して、ソフトウェア構造変更支援システムの実施例について説明する。
【００１４】
ソフトウェア構造変更支援システムは、例えば、大規模システムを対象としたソフトウェア構造の変更を支援する。このような大規模システムは、仕様書とソースコードの乖離が大きく、開発してから数十年経過しているものも多く存在するため、全体のソフトウェア構造や設計指針などを把握することが困難である場合が多い。
【００１５】
そこで、拠点の特性に合わせた機能を提供しつつも、環境の変化にシステムを柔軟かつ迅速に追従させるシステム刷新の仕組みが必要となる。このため、拠点ごとに機能を作りこむのではなく、各拠点の業務システムを構成する最小機能の単位でプログラムをモジュール化する手法が考えられる。ここで、モジュールとは、ある機能を実現するプログラムのまとまりのことを言う。この手法では、モジュールの組み合わせでシステムの動作をさせつつ、各モジュールの適切な管理によって各拠点での現行モジュールの改修追加等の変更を必要最小限にする。
【００１６】
システム改修の方法の一例して、数十年に渡り開発保守してきたＣＯＢＯＬなどのレガシー言語によるバッチプログラムとシェルで動作するような大規模情報システムを、ＪＡＶＡ（登録商標）言語等に変換して同様の機能を実現する方法（システムモダナイゼーション）が挙げられる。
【００１７】
この場合には、単なる言語変換をするだけではなく、ソフトウェア構造を適切に解析し、適切なクラスやパッケージ化を行い、必要に応じて機能改修や機能追加をすることでシステムを再構築することが必要となる。なお、その際には既存ソフトウェアに関して熟知していなくとも、適切なクラスやパッケージ化を再設計することが望まれる。
【００１８】
ソフトウェア構造解析の結果、構造やステップ数が類似のものがあったとしても、複数の開発者による改修を繰り返してきたシステムにおいては改修の容易性は異なる可能性がある。よって、実行頻度や実行タイミング等の業務利用方法や致命的なバグの発生回数等の稼動実績などの保守履歴に基づいて、既存の大規模なシステムのソフトウェア構造を、別のシステムのソフトウェア構造に変更した方が良い場合がある。
【００１９】
実施例のソフトウェア構造変更支援システムでは、既存の大規模なシステムのソフトウェア構造を、別のシステムのソフトウェア構造に変更してシステムの刷新（システムモダナイゼーション）を行う。
【００２０】
最初に、図１を参照して、ソフトウェア構造変更支援システムの構成について説明する。
図１に示すように、ソフトウェア構造変更支援システムは、ソフトウェア構造変更支援装置１０、表示装置２０及び業務システム３０を有する。ソフトウェア構造変更支援装置１０は、ネットワーク７０を介して表示装置２０と業務システム３０に接続されている。ここで、図１では、表示装置２０と業務システム３０は一つだけ示されているが、複数個有しても良い。
【００２１】
ソフトウェア構造変更支援装置１０は、業務システム３０からソフトウェア構造評価対象である業務システムのアプリケーションログを取得し、ソフトウェア構造の解析とモジュール分割、及び前記処理に利用するソフトウェア構造解析結果と解析に使用する評価値を管理する装置である。なお、ソフトウェア構造変更支援装置１０は、業務システム３０のソースコード管理システム上の一機能として構成してもよい。
【００２２】
図２を参照して、図１に示したソフトウェア構造変更支援装置１０のソフトウェア構成について説明する。
図２に示すように、ソフトウェア構造変更支援装置１０は、ソフトウェア構造解析手段１０１１と評価値算出手段１０１２を有するソフトウェア構造解析部１０１、モジュール分割手段１０２１と傾斜管理手段１０２２を有するモジュール評価部１０２、ソフトウェア構造データテーブル１１１、実績データテーブル１１２、エッジ評価データテーブル１１３、モジュール評価データテーブル１１４及び傾斜データテーブル１１５を備える。これらの実態は、図４に示す主記憶部１０３に格納されたソフトウェアプログラム及びデータであり、実行時にはＲＡＭに読み込まれてＣＰＵ（プロセッサ）によって実行される。
【００２３】
ソフトウェア構造解析手段１０１１は、ソースコードを解析し、プログラムとなるノード及びプログラムの呼び出し関係となるエッジを特定して得られたソフトウェア構造データをソフトウェア構造データテーブル１１１に格納する。
【００２４】
評価値算出手段１０１２は、ソフトウェア構造データテーブル１１１に格納されたソフトウェア構造データと、実績データテーブル１１２に格納された実績データと、ネットワーク７０を介して業務システム３０から収集したアプリケーションログとに基づいて、エッジの評価値を算出してエッジ評価データテーブル１１３に格納する。
【００２５】
モジュール分割手段１０２１は、表示装置２０にて受け付けたモジュール分割数に基づいて、プログラムの最小カットを実施する。前記モジュール分割手段１０２１が動作した結果は、モジュール評価データテーブル１１４に格納される。
【００２６】
傾斜管理手段１０２２は、表示装置２０にて受け付けたモジュール境界の変更前後のエッジの重みを基に、エッジを評価する重み付け変数の傾斜を算出し、傾斜データテーブル１１５に格納する。
【００２７】
次に、図２を参照して、ソフトウェア構造変更支援装置１０の機能について説明する。
まず、ソフトウェア構造解析手段１０１１は、対象業務システム３０のソースコードを取得し、プログラム（関数）及びプログラムの呼び出し関係を解析する。プログラム（関数）をノードとして定義し、プログラム（関数）の呼び出し関係を方向付きエッジとして定義して、ソフトウェア構造データテーブル１１１に格納する。
【００２８】
次に、評価値算出手段１０１２は、ネットワーク７０を介して業務システム３０からアプリケーションログを取得し、実績データテーブル１１２に格納する。また、前記評価値算出手段１０１２は、解析したソフトウェア構造データテーブル１１１と実績データテーブル１１２を参照し、エッジに重み付けを実施し、算出した評価値をエッジの重みとしてエッジ評価データテーブル１１３に格納する。前記結果はソフトウェア構造変更支援装置１０からネットワーク７０を介して送信し、表示装置２０がソフトウェア構造をグラフとして表示する。
【００２９】
ソフトウェア構造変更支援装置１０は、表示装置２０からユーザが指定したモジュール分割数を受け付け、モジュール分割手段１０２１を動作させる。モジュール分割手段１０２１は、解析したソフトウェア構造に対し、受け付けた分割数になるまで最小カットを実施する。具体的には、ソフトウェア構造のグラフに対して、ｓ−ｔ最小カット／最大フロー・ネットワーク・アルゴリズム（ｓ−ｔ  ｍｉｎｉｍｕｍ  ｃｕｔ／ｍａｘｉｍｕｍ  ｆｌｏｗ  ｎｅｔｗｏｒｋ  ａｌｇｏｒｉｔｈｍ）を適用する。
【００３０】
前記分割されたモジュール情報は、モジュール評価データテーブル１１４に格納すると共に、ソフトウェア構造変更支援装置１０がネットワーク７０を介して表示装置２０に送信する。表示装置２０は、ソフトウェア構造の表示に加えてモジュール情報を付加して表示する。これにより、ユーザは最初に閲覧したグラフ構造で表現されたソフトウェア構造がモジュールごとに表示されることを確認する。
【００３１】
なお、ユーザが前記表示結果についてモジュールを変更するよう操作した場合、ソフトウェア構造変更支援装置１０は変更操作を受け付け、傾斜管理手段１０２２を呼び出す。傾斜管理手段１０２２は、ユーザの操作に伴い変更されたモジュールのエッジと、変更前のエッジの重み付けに参照した要素を比較して、要素間の傾斜を変更して傾斜データテーブル１１５を更新する。モジュール分割手段１０２１は、更新された傾斜データ１１５を参照して再度モジュール分割を実施し、モジュール評価データ１１４を更新する。変更されたモジュールを、再度表示装置２０にて表示することにより、ユーザに変更に伴う他のプログラム（ノード）の分割結果が再表示される。
【００３２】
なお、傾斜データテーブル１１５及びモジュール評価データテーブル１１４はユーザごとに作成して管理してもよい。また、モジュール評価データテーブル１１４にてモジュール評価の履歴を管理しておき表示装置２０に送信することにより、表示装置２０にてユーザ操作を受け付ける前後でどの部分が変わったかがわかるよう、変更前後の境界を示しても良い。
【００３３】
図２で示したソフトウェア構成において、傾斜管理手段１０２２を備えることにより、ユーザの設計方針も踏まえたモジュール構成を導出することができる。
【００３４】
次に、図３を参照して、ソフトウェア構造解析部１０１の処理を詳細に説明する。
【００３５】
まず、ソフトウェア構造解析手段１０１１は、対象の業務システム３０のソースコードを取得し、プログラム（関数）及びプログラムの呼び出し関係を解析する。プログラム（関数）をノードとして定義し、プログラム（関数）の呼び出し関係を方向付きエッジとするノードとして定義して、ソフトウェア構造データ１１１のノード情報テーブル１１１１とエッジ情報テーブル１１１２を更新する。
【００３６】
次に、評価値算出手段１０１２は、ネットワーク７０を介して業務システム３０からアプリケーションログを取得し、実績データテーブル１１２の実績テーブル１１２１及び開発者情報テーブル１１２２を更新する。また、評価値算出手段１０１２は、解析したノード情報テーブル１１１１、エッジ情報テーブル１１１２、実績テーブル１１２１及び開発者情報テーブル１１２２の情報に基づいてエッジに重み付けを実施し、エッジ評価データテーブル１１３のエッジ評価値テーブル１１３１に格納する。
【００３７】
図１に示したソフトウェア構造変更支援装置１０と業務システム３０は、それぞれサーバ装置により構成され、そのサーバ装置のハードウェア構成は図４に示す構成を有する。
【００３８】
図４に示すように、サーバ装置１０１は、主制御部１０３、主記憶部１０４、入力部１０５、出力部１０６及び通信部１０７を備える。そして、サーバ装置１０１は、通信部１０７を介してネットワーク７０に接続されている。
【００３９】
主制御部１０３は、主記憶部１０４に記録されたプログラムコードをプロセッサが実行することで、サーバ装置１０１における情報処理を制御する。主記憶部１０４は、サーバ装置１０１に関する情報を不揮発的に記憶する。入力部１０５は、サーバ装置１０１に関する情報を手動で入力する必要がある際に、ユーザがサーバ装置１０１に対して入力する。出力部１０６は、サーバ装置１０１に関する情報を出力する必要がある際に、サーバ装置１０１がユーザに対して出力する。通信部１０７は、ネットワーク７０を介して、他サーバ装置の通信部１０７と接続し、他サーバ装置と情報を伝達しあう。
【００４０】
また、図１に示した表示装置２０は、所定の入力を受け付けてソフトウェア構造を表示する端末装置である。例えば、表示装置２０からモジュールの分割数を指定し、指定された分割数に応じて、モジュールの境界を変更して表示装置２０に表示する。あるいは、表示装置２０からモジュールの境界を指定し、指定された境界に応じて、モジュールの構成を変更して表示装置２０に表示する（図１３Ａ、図１３Ｂ、図１４参照）。
【００４１】
図５Ａ、図５Ｂは、ソースコード解析の結果得られたプログラム情報を管理するソフトウェア構造データテーブル１１１のデータ構造である。ソフトウェア構造データテーブル１１１は、ノード情報テーブル１１１１とエッジ情報テーブル１１１２から成る。
【００４２】
まず、図５Ａは、ノード情報テーブル１１１１のデータ構造を示す。本データ構造は、プログラム（関数）ごとにノードＩＤを割り当て、各ノードに対して、プログラムを一意に特定可能なパス、プログラムが参照する入力データＩＤ、プログラム動作の結果アウトプットする出力データＩＤ及び呼び出し基プログラムＩＤを格納する。入力データ及び出力データは一意に特定可能なＩＤにて格納する。
【００４３】
図５Ｂは、エッジ情報テーブル１１１２のデータ構造を示す。本データ構造は図５Ａで示したプログラム間の呼び出し関係ごとにエッジＩＤを割り当て、各呼び出し関係に対して、エッジの呼び出し元プログラムＩＤ及び呼び出し先プログラムＩＤを格納する。呼び出し元プログラムＩＤ及び呼び出し先プログラムＩＤはノード情報テーブル１１１１に格納したプログラムＩＤを使用する。
【００４４】
なお、エッジは方向付きのため、参照元と参照先のノードを特定できるよう分割して保持し、例えば一つのプログラムから複数のプログラムを呼び出している場合は、呼び出し元プログラムＩＤが同一で、呼び出し先プログラムＩＤが異なるエッジＩＤが作成される。
【００４５】
図６Ａ、図６Ｂは、エッジの重み付けに利用する要素を管理する実績データテーブル１１２のデータ構造である。実績データテーブル１１２は、実績テーブル１１２１と開発者情報テーブル１１２２から成る。
【００４６】
まず、図６Ａは、実績テーブル１１２１のデータ構造を示す。実績テーブル１１２１は、ノード情報テーブル１１１１で管理するノードＩＤごとに、開発者ＩＤ、バグ発生数及び最終実行日時を格納する。開発者ＩＤは、ソースコード管理システムなどから得られる当該プログラムの開発者を一意に特定可能なＩＤである。複数の開発者が関与する場合は、関与順に全て格納する。
【００４７】
バグ発生数は、ソースコード管理システムにおいて該当するプログラムが特定可能な状態で管理されるプログラムに関する課題（イシュー）の数やアプリケーションログからバグと定義された件数の数を格納する。また、最終実行日時は、アプリケーションログを解析した結果得られる最終実行日時を示す。実績テーブル１１２１については、リポジトリのソースコードが改修される都度、あるいは一定期間ごとにログを解析して、関連する要素をその都度更新する。
【００４８】
なお、本実施例では、管理する実績情報を開発者ＩＤ、バグ発生数、最終実行日時としたが、プログラムステップ数やクリティカルなバグの発生数などシステムの設計方針に基づき別な情報を管理してもよい。
【００４９】
図６Ｂは、開発者の属性情報を管理する開発者情報テーブル１１２２である。本テーブルでは、一意に特定可能な開発者ＩＤに対し、開発者の経験年数、対象システムにおいて開発したプログラムとバグの発生数及び開発者のスキルを格納する。開発者のスキルは、例えば、相対的に５段階評価で総合的にランクを管理する。開発者情報テーブル１１２２についても、リポジトリのソースコードが改修される都度、関連する要素をその都度更新する。
【００５０】
図７は、エッジの評価値を管理するエッジ評価データテーブル１１３のデータ構造である。図７に示すように、エッジ評価データデータテーブル１１３は、エッジを一意に特定可能なエッジＩＤ及び評価値を保持している。ここで、評価値とは、エッジに付与する重みのことであり、評価値算出手段１０１２を実施した都度更新される。
【００５１】
図８は、モジュール評価データテーブル１１４のデータ構造である。モジュール評価データテーブル１１４は、モジュール分割手段１０２１が動作した結果、分割されたモジュールと、モジュールに内包されるノードＩＤを一意に特定可能なＩＤで管理するものである。例えば、Ｍ１のモジュールは、ノードＰ１、Ｐ２、Ｐ３で構成される。
【００５２】
図９は傾斜データテーブル１１５のデータ構造である。傾斜データテーブル１１５は、図７に示す各エッジの評価値を算出するために参照するデータ項目、すなわち、図６Ａ、図６Ｂに示す実績データ１１２等のデータ項目間の相対的な重要性を傾斜値として格納するものである。ここで、初期値は、各要素の重要性は同じものとして扱い全て１．０とする。
【００５３】
なお、傾斜データデはユーザごとに異なる可能性があるため、表示装置２０を参照し、操作をするユーザを一意に特定可能なユーザＩＤごとに値を管理し、ユーザによる境界変更操作が行われた場合にその都度更新する。例えば、図９のユーザＵ１の場合は、全ての要素が同係数、すなわち、初期値のままでモジュール分割を行うよう管理されている。一方、ユーザＵ２の場合は、開発者ランクが０．９、バグ発生数が１．２と要素によって異なり、エッジの重み付けの際にはバグ発生数が開発者ランクや最終実行日時と比べて重視されるよう管理されていることを示す。
【００５４】
次に、図１０を参照して、ソフトウェア構造解析部１０１の動作について説明する。
【００５５】
ソフトウェア構造解析部１０１は、まず、リポジトリにソースコードが追加されたことの検知をトリガとして動作し、ソースコードの解析を行う（Ｓ１０１）。なお、リポジトリとは、ソースコードや定義ファイル、開発履歴等が一元管理されるシステムのデータ保管庫のことを指す。
【００５６】
次に、ステップ１０１で解析した結果を元にソフトウェア構造データテーブル１１１を更新する（Ｓ１０２）。
【００５７】
次に、リポジトリ情報やアプリケーションログを解析して実績データテーブル１１３を更新する（Ｓ１０３）。
【００５８】
次に、参照したデータを元に各エッジの重みを算出（Ｓ１０４）する。次に、エッジ評価データテーブル１１３を更新する（Ｓ１０５）。このようにして、ソースコード、バグ発生数や開発者スキルなどのエッジを評価する要素の変更を管理する。
【００５９】
ここで、図１５を参照して、ステップＳ１０４で実施するエッジの重み付け方法について述べる。例として、図１５に示すソフトウェア構造１５０１を解析する場合を示す。図１５のソフトウェア構造１５０１では、ＰＧ１からＰＧ５まで一意に特定されたノードが呼び出し関係を持っており、それぞれデータの入出力を持っている。なお、図１５では、入出力データはＤ１からＤ７までのＩＤで示している。
【００６０】
まず、ソフトウェア構造データテーブル１１１のノード情報テーブル１１１１に格納した各ノードＩＤについて、テーブル１５０２に示すように、参照データ、プログラム呼び出し元の開発者、バグ発生数、最終実行日時を更新する。図１５では、説明の都合上、ソフトウェア構造１５０１のノードのみを記載している。
【００６１】
次に、テーブル１５０３に示すように、ノード間をつなぐエッジについて、データ参照関係、呼び出し元の開発者ランク、バグ発生数の差、実行時刻の差、を相対評価でそれぞれ５段階のスコアを付ける。データ参照関係は呼び出し元プログラムで出力したデータと同じデータを参照しているほど関係性が高いものとしてスコアを高くし、呼び出し元のデータを参照していない場合は１を設定する。呼び出し元の開発者ランクについては、呼び出し先の開発者が呼び出し関係を生成していることから呼び出し元の開発者のランクを設定する。
【００６２】
なお、開発者ランクは、開発者情報テーブル１１２２を参照し、経験年数６１２、当該システムにおけるバグ発生数６１３、スキル６１４から開発者スキルを５段階で算出して設定する。バグ発生数の差は、エッジの呼び出し元と呼び出し先のノードに格納されているバグ発生数の差分を算出し、その値を５段階でスコア付けする。実行時刻の差についても同様に、エッジの呼び出し元と呼び出し先のノードに格納されている最終実行日時の差分を算出し、その値を５段階でスコア付けする。
【００６３】
最後に、算出した各スコア、すなわち、データ参照関係、開発者ランク、バグ発生数の差及び実行時刻の差の積をエッジの重みとして設定する。例えば、テーブル１５０３に示すように、エッジＩＤがＥ１のエッジは、データ参照関係のスコアが２、呼び出し元の開発者ランクが５、バグ発生数の差が１、実行時刻の差が５とスコア付けされ、エッジの重みは５０となる。他のエッジについても同様の方法にて重み付けを実施する。
【００６４】
なお、本実施例では開発者が複数いる場合は、最終更新に関与した開発者でランク付けをしたが、開発者の人数や改修規模などから開発者スキルを設定しても良い。
【００６５】
次に、図１１を参照して、ユーザ操作を受け付けてからモジュール分割を実施し、モジュール粒度を表示するモジュール分割手段２０２の動作について説明する。モジュール分割手段２０２は、ユーザの指定するモジュール分割数を受け付けた後に動作する。
【００６６】
まず、表示装置２０がソフトウェア構造データとエッジ評価データを取得し（Ｓ２０１）、ソフトウェア構造を表示する（Ｓ２０２）。
【００６７】
次に、ユーザが指定したモジュール分割数を受信し（Ｓ２０３）、モジュール分割数をソフトウェア構造評価装置１０に送信する（Ｓ２０４）。ソフトウェア構造解析部１０１は、受け付けたモジュール分割数を満たすまで最小カットを実行してモジュール分割を実行し（Ｓ２０５）、モジュール評価データテーブル１１４を更新する（Ｓ２０６）。そして、処理の完了を表示装置２０に通知する（Ｓ２０７）。表示装置２０は、モジュール評価データを取得し（Ｓ２０８）、モジュール境界を表示する（Ｓ２０９）。
【００６８】
次に、図１２を参照して、ユーザの境界変更操作に基づき、再度モジュール分割を実施する動作について説明する。
【００６９】
まず、表示装置２０は、モジュール評価データを取得し（Ｓ３０１）、既に表示されているソフトウェア構造に加えてモジュール境界を表示する（Ｓ３０２）。ユーザがモジュール境界を変更した場合には（Ｓ３０３）、表示装置２０が変更操作を行ったユーザ情報と変更されたモジュール境界のエッジＩＤをソフトウェア構造評価装置１０に送信する（Ｓ３０４）。
【００７０】
ソフトウェア構造評価装置１０は、モジュール境界の変更情報と変更前のエッジの情報を元にエッジの重み付けに使用する要素間の傾斜値を再計算して（Ｓ３０５）、エッジ評価値データテーブル１１３の傾斜値を更新する（Ｓ３０６）。
【００７１】
ソフトウェア構造変更支援装置１０は、再度最小カットを実行してモジュール分割し（Ｓ３０７）、モジュール評価データテーブル１１４を更新する（Ｓ３０８）。更新が完了すると、表示装置２０に処理完了通知を送信する（Ｓ３０９）。
【００７２】
表示装置２０は、モジュール評価データを取得し（Ｓ３１０）、モジュール境界を表示する（Ｓ３１１）。なお、再計算されたモジュール境界は当初算出されたモジュール境界と線種や色を変更して表示してもよい。
【００７３】
図１３は、表示装置２０の動作結果を表示する画面例を示したものであり、図１３Ａがソフトウェア構造を示す初期表示画面５０１、図１３Ｂがモジュール評価部１０２動作後の表示画面である。
【００７４】
まず、図１３Ａでは、ソフトウェア構造解析部１０１が動作し、ソフトウェア構造をグラフにした結果を初期画面として表示する。ソフトウェア構造は、プログラムを示すノードが丸、プログラムの呼び出し関係を示すエッジを矢印で表示する。なお、ノードは呼び出し関係の最初のノードを始点として実行時系列順に表示される（５０２）。図１３Ａの画面例では、ＰＧ１からＰＧ５のノード、ＰＧ６からＰＧ１４のノードに呼び出し関係がある。そして、ＰＧ１とＰＧ６では、ＰＧ１からＰＧ５のノードが最初に実行され、その後、ＰＧ６からＰＧ１４のノードが実行される。
【００７５】
プログラムを示すノードは、ノードの実績データテーブル１１２から得られるバグ数やステップ数に応じて色や濃淡、形の大きさなど表示方法を変更しても良い。例えば、ノード５０１２は、バグ発生数の多いノードとして濃い色で表示している。このように表現を変更することにより、全体のノードのうち、ある値が高いなど特徴のあるノードの把握が容易になる。
【００７６】
また、プログラム間の呼び出し関係を示すエッジもエッジの重みに応じて線種や太さなど表示方法を変更しても良い。例えば、エッジ５０１３は、エッジの重みが大きいエッジであることを線の太さで表現している。また、図１３Ａの画面例では、ノードにノードＩＤを表示し、エッジには何も表示していないが、これらの属性情報は表示／非表示の切り替え又は表示する変数を変更することができる。例えば、ノードのラベルをノードＩＤではなく開発者ＩＤで表示することや、エッジのラベルを非表示ではなく、重み付けした値を表示することも可能である。
【００７７】
図１３Ａに示す初期画面では、プログラムの呼び出し関係は把握できるものの、モジュールは判断しにくい。そこで、ユーザにモジュール分割数５０４を指定させ、図１３Ｂに示すように表示画面を変更し、モジュールの境界を把握できるようにする。図１３Ａ、図１３Ｂに示す画面ではバー５０４の形状で分割数を表示しており、バー５０４をスライドさせて分割数を指定する。これにより、図１３Ｂの５０１４に示すように点線でモジュールの境界を表示する。なお、バー５０４は変更する都度最小カットの数が変化し、この数に応じて画面に表示されるモジュールの数が変化する。これにより、ユーザは試行錯誤を繰り返しながら適切なモジュールの境界を把握し検討することができる。
【００７８】
なお、ユーザがバグの多いプログラム（例えば、ＰＧ２）だけを切り離したい場合など、一部のモジュール構成を変更したい場合は、図１３Ｂの５０１５に示す矢印でモジュールの境界を指定して動かせばよい。矢印５０１５で境界５０１４（ＰＧ３とＰＧ４の間のエッジ）を変更すると、傾斜管理手段１０２２が動作して、他のノードの境界を変更することができる。例えば、図１３Ｂでは、ＰＧ３とＰＧ４の間が境界となっているが、ＰＧ２がバグの多いプログラムで、ＰＧ３への影響を少なくしたい場合、境界をＰＧ３とＰＧ４ではなく、ＰＧ２とＰＧ３にすることが考えられる。境界変更時の表示方法については図１４にて述べる。
【００７９】
なお、モジュール境界を確定し、それ以降のモジュール境界変更の影響を避けたいモジュールがある場合は、確定ボタン５０３を押下すればよい。モジュール境界が確定された対象については、モジュール分割数の変更や境界の変更を受け付けず表示し続けることができる。この動作により、ユーザの意図を反映しつつ、適切なモジュール境界を設定することが可能となる。
【００８０】
図１４は、図１３にてＰＧ３とＰＧ４のエッジの境界を変更した後、再計算されたモジュール境界を表示する画面例を示したものである。図１４に示す通り、図１３ではＰＧ３とＰＧ４の間にあったモジュール境界６０３の線種が変更され、新たにＰＧ２とＰＧ３に境界が表示されている。また、ＰＧ３とＰＧ４の境界変更に伴い、ＰＧ６以降のモジュール境界も再計算され、ＰＧ１１とＰＧ１２の境界が変更になったことが分かるよう表示される。
【００８１】
なお、変更前後の線の表示に関して、表示有無を切り替えても良い。図１４の６０５に示す通り、ユーザの変更の都度モジュール境界を管理しておき、画面に変更履歴と表示可否を選択可能なボタンを配置することにより、エッジの重みの傾斜が一律であった初期値の境界と、ユーザ操作の結果変更された境界との表示を切り替えることができる。
【００８２】
上記実施例によれば、静的解析からだけでは得られない保守履歴を元に最適なソフトウェア構造が特定可能となる。このため、大規模システムを保守性の高い構成に再構成することができる。
【００８３】
また、ソフトウェア構造と保守履歴の可視化により、バグの多いプログラムを有し保守上問題のあるプログラムの特定が容易になる。このため、重点保守対象となるモジュールの特定にかかる工数を削減しつつ、重点保守対象から改修などの対策を実施することで効率的にシステム全体の保守性を高めることができる。
【００８４】
また、ソフトウェア構造と既存のプログラムの名称等に依存せずにモジュール構成候補を把握することができるため、システム刷新時のモジュール構造の検討計画工数を削減することができる。また、表示されたソフトウェア構造に基づき、改修の必要性の高いプログラムの発見も容易になるため、効率よい改修計画を立案することができる。より具体的には、バグの少ないモジュールやモジュールを構成するノードが少ないモジュールをスキルの低い開発者に担当させ、バグの多いモジュールを優先して改修対象とするなどの施策を計画することが容易になる。
【符号の説明】
【００８５】
１０  ソフトウェア構造変更支援装置
２０  表示装置
３０  業務システム
１０１  ソフトウェア構造解析部
１０２  モジュール評価部
１０１１  ソフトウェア構造解析手段
１０１２  評価値算出手段
１０２１  モジュール分割手段
１０２２  傾斜管理手段
１１１  ソフトウェア構造データテーブル
１１２  実績データテーブル
１１３  エッジ評価データテーブル
１１４  モジュール評価データテーブル
１１５  傾斜データテーブル
【図１】
2018151713.tif 000003
【図２】
2018151713.tif 000004
【図３】
2018151713.tif 000005
【図４】
2018151713.tif 000006
【図５Ａ】
2018151713.tif 000007
【図５Ｂ】
2018151713.tif 000008
【図６Ａ】
2018151713.tif 000009
【図６Ｂ】
2018151713.tif 000010
【図７】
2018151713.tif 000011
【図８】
2018151713.tif 000012
【図９】
2018151713.tif 000013
【図１０】
2018151713.tif 000014
【図１１】
2018151713.tif 000015
【図１２】
2018151713.tif 000016
【図１３Ａ】
2018151713.tif 000017
【図１３Ｂ】
2018151713.tif 000018
【図１４】
2018151713.tif 000019
【図１５】
2018151713.tif 000020