特許 7255420 資産管理装置、資産管理方法および資産管理プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-04-03

(45)【発行日】2023-04-11

(54)【発明の名称】資産管理装置、資産管理方法および資産管理プログラム

(51)【国際特許分類】

   G06F 8/75 20180101AFI20230404BHJP

【ＦＩ】

G06F8/75

【請求項の数】 6

(21)【出願番号】P 2019152021

(22)【出願日】2019-08-22

(65)【公開番号】P2021033562

(43)【公開日】2021-03-01

【審査請求日】2022-05-17

(73)【特許権者】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】上村 学

(72)【発明者】

【氏名】松尾 昭彦

【審査官】関口 明紀

(56)【参考文献】

【文献】特開２０１８－１８１００５（ＪＰ，Ａ）

【文献】特開２０１３－１４８９８７（ＪＰ，Ａ）

【文献】特開２００６－３０２１３５（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ８／７５

(57)【特許請求の範囲】

【請求項1】

プログラム資産を構成する複数のプログラムと複数のデータのうち、他のプログラムから呼び出される第１のプログラムを特定する第１特定部と、
前記第１のプログラムのうち、前記複数のデータのいずれかのデータを内部に保持する、または、前記複数のデータのいずれかのデータを更新する、第２のプログラムを特定する第２特定部と、
前記複数のプログラムと前記複数のデータとを依存関係に基づき、プログラムとデータとを関連付けるサービス部品に分類する場合に、前記第２のプログラムを独立したサービス部品に分類する分類部と
を有することを特徴とする資産管理装置。

【請求項2】

前記第２特定部は、前記第１のプログラムのうち、データを更新する構文が記述されているプログラム、ファイルを書き込む構文が記述されているプログラム、または、共有メモリの領域を更新する構文が記述されているプログラムに該当するプログラムを、前記第２のプログラムと特定する、ことを特徴とする請求項１に記載の資産管理装置。

【請求項3】

前記分類部は、他のプログラムから呼び出されない起点となる起点プログラムを特定し、前記起点プログラムが呼び出す呼出先プログラムが前記第２のプログラムに該当しない場合は、前記起点プログラムと前記呼出先プログラムとを同じサービス部品に分類し、前記呼出先プログラムが前記第２のプログラムに該当する場合は、前記起点プログラムと前記呼出先プログラムとを別々のサービス部品に分類する、ことを特徴とする請求項１または２に記載の資産管理装置。

【請求項4】

前記プログラム資産から複数のサービス部品に分類した結果を表示する際に、前記起点プログラムおよび前記第２のプログラムを、他のプログラムおよびデータとは異なる形式で表示する表示制御部をさらに有することを特徴とする請求項３に記載の資産管理装置。

【請求項5】

コンピュータが、
プログラム資産を構成する複数のプログラムと複数のデータのうち、他のプログラムから呼び出される第１のプログラムを特定し、
前記第１のプログラムのうち、前記複数のデータのいずれかのデータを内部に保持する、または、前記複数のデータのいずれかのデータを更新する、第２のプログラムを特定し、
前記複数のプログラムと前記複数のデータとを依存関係に基づき、プログラムとデータとを関連付けるサービス部品に分類する場合に、前記第２のプログラムを独立したサービス部品に分類する
処理を実行することを特徴とする資産管理方法。

【請求項6】

コンピュータに、
プログラム資産を構成する複数のプログラムと複数のデータのうち、他のプログラムから呼び出される第１のプログラムを特定し、
前記第１のプログラムのうち、前記複数のデータのいずれかのデータを内部に保持する、または、前記複数のデータのいずれかのデータを更新する、第２のプログラムを特定し、
前記複数のプログラムと前記複数のデータとを依存関係に基づき、プログラムとデータとを関連付けるサービス部品に分類する場合に、前記第２のプログラムを独立したサービス部品に分類する
処理を実行させることを特徴とする資産管理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、資産管理装置、資産管理方法および資産管理プログラムに関する。

【背景技術】

【0002】

コンピュータシステムの発達により、世の中の様々な場面でコンピュータシステムが活用されている。一度構築したコンピュータシステムでも歳月を経ることで、改良を行う必要性あるいはシステム全体を見直す必要性が生じることがある。このとき、既に作成したプログラムの一部に修正を行うことがあり、既存のシステムの仕様を理解する必要がある。しかし、ソフトウェアは大規模になるとその仕様は複雑なものとなり、仕様の把握や変更は容易ではない。また、膨大なプログラムを対象とした時、プログラム間の関係やデータとの関係数も膨大になるため、全ての関係を基にソフトウェアを分割することは容易ではない。

【0003】

近年では、大規模システムを対象に、ソフトウェアを理解可能な部分集合であるサービス部品に分割する技術として、プログラムの呼び出し関係から、自動的に部分集合を抽出してクラスタリングする技術が知られている。また、部分集合を抽出する際に、外部から更新されるデータは、外部に共通データとして定義し、共通データを除いて新たに切り出しの単位を定義した上で、クラスタリングする技術も知られている。また、モダナイゼーションの対象とするアプリケーションの優先順位を直感的に分かりやすくするために、アプリケーションの機能構造を自動的に地図化する技術も知られている。

【先行技術文献】

【特許文献】

【0004】

【文献】特開２０１２－０９８９０２号公報

【文献】特開２０１８－１８１００５号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかしながら、上記技術では、アプリケーションが有する複数のプログラムやデータを、サービスを実行する部品であるプロセス単位の部分集合で配置する場合に、プログラムの配置によっては、アプリケーションの構造が理解しにくくなる。

【0006】

例えば、あるプログラムを複数のプロセスに割当てると、デットロックなどを誘発させることがあり、排他管理を考慮して正しくクラスタリングできず、結果として、プログラムの修正が実行できない。また、デットロックを抑制するために、あるプログラムをどのプロセスにも所属させないようにクラスタリングすることも考えられるが、独立したプログラムが多発し、アプリケーションの構造が理解できなくなる。

【0007】

一つの側面では、アプリケーションの構造を理解し易い形式で分類することができる資産管理装置、資産管理方法および資産管理プログラムを提供することを目的とする。

【課題を解決するための手段】

【0008】

第１の案では、資産管理装置は、プログラム資産を構成する複数のプログラムと複数のデータのうち、他のプログラムから呼び出される第１のプログラムを特定する第１特定部を有する。資産管理装置は、前記第１のプログラムのうち、前記複数のデータのいずれかのデータを内部に保持する、または、前記複数のデータのいずれかのデータを更新する、第２のプログラムを特定する第２特定部を有する。資産管理装置は、前記複数のプログラムと前記複数のデータとを依存関係に基づき、プログラムとデータとを関連付けるサービス部品に分類する場合に、前記第２のプログラムを独立したサービス部品に分類する分類部を有する。

【発明の効果】

【0009】

一実施形態によれば、アプリケーションの構造を理解し易い形式で分類することができる。

【図面の簡単な説明】

【0010】

【図1】図１は、実施例１にかかる分析装置を説明する図である。

【図2】図２は、一般的な分析手法の問題点を説明する図である。

【図3】図３は、重複が問題となる例を説明する図である。

【図4】図４は、重複により分類が容易になる例を説明する図である。

【図5】図５は、実施例１に係る分析装置の機能構成を示す機能ブロック図である。

【図6】図６は、プログラム資産ＤＢに記憶されるプログラム全体の例を示す図である。

【図7】図７は、重複可能と判定される例を説明する図である。

【図8】図８は、重複不可と判定される例を説明する図である。

【図9】図９は、重複不可と判定される例を説明する図である。

【図10】図１０は、重複不可と判定される例を説明する図である。

【図11】図１１は、重複不可と判定される例を説明する図である。

【図12】図１２は、プログラムの呼出構造および分類を説明する図である。

【図13】図１３は、サービス部品候補の生成結果を説明する図である。

【図14】図１４は、分析結果および出力例を説明する図である。

【図15】図１５は、全体的な処理の流れを示すフローチャートである。

【図16】図１６は、重複判定処理の流れを示すフローチャートである。

【図17】図１７は、プログラム群生成処理の流れを示すフローチャートである。

【図18】図１８は、ハードウェア構成例を説明する図である。

【発明を実施するための形態】

【0011】

以下に、本願の開示する資産管理装置、資産管理方法および資産管理プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。また、各実施例は、矛盾のない範囲内で適宜組み合わせることができる。

【実施例1】

【0012】

［分析装置の説明］
図１は、実施例１にかかる分析装置１００を説明する図である。図１に示すように、分析装置１００は、複数のプログラムと複数のデータとを含むプログラム資産に対して疎結合分析を実行し、アプリケーションなどのプログラム資産内にプログラムやデータベースなどを分割や分類して、アプリケーションの構造を分析した分析結果を生成する。つまり、分析装置１００は、資産管理装置の一例であり、プログラム資産の内部構造の把握と、機能やデータをサービスとして切出しやすい形への再構造化を行う。

【0013】

一般的に、あるシステムへ適用されたプログラム資産は、システムの改変、増築、ネットワークなどの周辺環境の変化に伴い、更新されていく。つまり、システムが長年使用されることにより、プログラム資産へプログラムやデータベースなどの部品（要素）の追加、プログラム資産内の部品の変更などが経年的に実行される。このように経年的に更新されるプログラム資産は、複数人によって更新されることから、正確な管理資料（更新資料）などがないことも珍しくない。このため、リバースエンジニアリングやプログラム構造の分析などを行う場合に、プログラム資産の全体を参照して、プログラム資産内に部品が他の部品とどのように関係しているのか、ある部品を更新するとどの部品に影響を与えるのかを分析して把握することは、システムエンジニアやプログラマであっても簡単ではない。

【0014】

近年、変化の激しい業務に合わせて、システムを迅速に変更することが求められている。例えば、産業流通の業務では、拠点追加や取引先の変更などが度々あり、それに合わせて、業務システムも変更していくことが要求される。しかし、以前の業務システムは、プログラム同士や、プログラムとデータとが一体となった構造になっていることが多く、システムを変更しようとすると、どこに影響が及ぶかわからない。この結果、改修が難しく、頻繁に変更することが出来ない。また、影響範囲を局所化するように分割しようとすると多くの依存関係を調べなければならないので、作業時間が膨大となっていた。

【0015】

一般的な手法の問題点として、サービスを実行するサービス部品であるプロセス別にプログラムを分割する場合、各プロセスに配置することを許容するプログラムと、重複配置せずに一つのプロセスに配置するべきプログラムとを判定できないことが挙げられる。

【0016】

図２は、一般的な分析手法の問題点を説明する図である。図２の（ａ）には、プログラム資産であるアプリケーションを示す。図２の（ａ）において、アプリケーションは、複数のプログラムから構成されるプロセスと、データベース等であるデータＸ、Ｙ、Ｚとから構成される。ここで、簡略化するために、プログラム１をＰＧ１などと表記し、プログラム間の呼出関係を実線の矢印で示し、データ更新の流れを破線の矢印で示し、データ参照の流れを太線の矢印で示す。つまり、ＰＧ１、ＰＧ１０、ＰＧ２０のそれぞれからＰＧ２とＰＧ３とが呼び出される依存関係がある。また、ＰＧ１とＰＧ１０とＰＧ３のそれぞれからデータＸへデータ更新の関係性、ＰＧ１からデータＹへデータ参照、ＰＧ２０からデータＺへデータ更新の関係性がある。

【0017】

このような状態で、一般的には、図２の（ｂ）に示すように、プログラムは必ず１のプロセスにのみ分類される手法や、図２の（ｃ）に示すように、関係するプログラムは全て、分類対象のプロセスに配置可能としてそれぞれに配置する手法が考えられる。つまり、プログラムの重複を行わずに分類するか、プログラムの重複を許容して分類することが行われる。ところが、アプリケーションの構造によっては、分類が正しく実行されず、デットロックなどの問題が発生し、却って、アプリケーションの構造が理解しにくくなることがある。

【0018】

図３は、重複が問題となる例を説明する図である。色々な処理から更新されるデータは、実行時に排他管理等のデータの管理が難しくなるので、データを更新する箇所は出来るだけ限定したい。また、データを複数の箇所で持つレプリケーションもあるが、更新箇所は限定した方が管理しやすい。具体的には、１つの資源の貸し借りをするようなシステムでは、各処理が直接データを参照や更新する形にすると、データアクセスが集中する。また、貸し出されているかどうかは、他の処理にそのデータが即時に反映されなければならないので、レプリケーションなどで分散して管理することが難しい。

【0019】

例えば、図３に示すように、サービス監視処理、イントラネット系サービス提供処理、提供サービス検索処理などの各処理から要求を受け付けて、プールされているＩＰ（Internet Protocol）アドレスの使用や解放を実行するアドレス管理プログラムを考える。この場合、各処理ではＩＰアドレスの貸し借りができればよいので、各処理がＩＰアドレスの貸し借りを直接行うように複数のプロセスにアドレス管理プログラムを配置するより、１つのプロセスで管理する方が効率的である。

【0020】

図４は、重複により分類が容易になる例を説明する図である。異なるデータに対して、同じ処理又は類似した処理を実行する場合がある。この場合、同じプログラムを呼び出す場合でも、プロセス毎に配置すればプロセス間の関係を簡潔にできることがある。

【0021】

例えば、図４に示すように、見積りの予定日を計算する見積もり取得予定日計算処理と納期の予定日を計算する納期予定日計算処理とのそれぞれからの要求に対して、指定営業日とカレンダ情報から予定日を返却する応答プログラムを考える。この応答プログラムの場合、データは引数で渡され、ＤＢなどのデータ更新は実行しない。このため、各処理（各プロセス）に応答プログラムを配置すれば、それぞれの処理の独立性が確保され、通信を削減できる。

【0022】

上述したように、処理の形態やデータの更新状況等により、分類対象の各プロセスに配置する方がよい場合と、分類対象の各プロセスには配置せずに独立した１つのプロセスとして分類する方がよい場合とがあり、その判断は難しい。

【0023】

そこで、実施例１にかかる分析装置１００は、プログラム資産を構成する複数のプログラムと複数のデータのうち、他のプログラムから呼び出される第１のプログラムを特定する。分析装置１００は、第１のプログラムのうち、複数のデータのいずれかのデータを内部に保持する、または、複数のデータのいずれかのデータを更新する、第２のプログラムを特定する。その後、分析装置１００は、複数のプログラムと複数のデータとを依存関係に基づき、プログラムとデータとを関連付けるサービス部品（プロセス）に分類する場合に、第２のプログラムを独立したサービス部品に分類する。

【0024】

このようにして、分析装置１００は、プロセス毎にプログラムを配置しても良いものか、プロセス毎に重複は配置せずに一つの単位に配置するべきものかを自動で判別し、適切に分類することで、アプリケーションの構造を理解し易い形式で分類することができる。

【0025】

［用語の説明］
ここで、実施例１で使用する用語について説明する。アプリケーションとは、プログラム全体を示し、本実施例では、業務ロジックなどが実装されたプログラムであるアプリケーションを対象とする。なお、本実施例では、オペレーティングシステムはプログラムに含まれないこととする。

【0026】

プログラムは、アプリケーションを構成する一部分であり、機能は、アプリケーションで実装されているロジックが提供する処理である。データは、データベースのテーブルやファイルなどである。サービスは、アプリケーションを一塊で実装するのではなく、複数のサービスを組み合わせて実現するマイクロサービスの１つの実行単位を指す。プロセスは、サービスの実行形態である。

【0027】

［機能構成］
図５は、実施例１に係る分析装置１００の機能構成を示す機能ブロック図である。図５に示すように、分析装置１００は、通信部１０１、記憶部１０２、制御部１１０を有する。

【0028】

通信部１０１は、他の装置との間の通信を制御する処理部であり、例えば通信インタフェースなどである。例えば、通信部１０１は、管理者端末から、処理開始の指示や分析対象のプログラム資産の入力を受け付ける。また、通信部１０１は、管理者端末などに、分析結果を送信する。

【0029】

記憶部１０２は、プログラムやデータを記憶する記憶装置の一例であり、例えばメモリやハードディスクなどである。この記憶部１０２は、プログラム資産ＤＢ１０３、重複判定結果ＤＢ１０４、分析結果ＤＢ１０５を記憶する。

【0030】

プログラム資産ＤＢ１３は、分析対象のアプリケーションであるプログラム資産を記憶するデータベースである。ここで記憶されるプログラム資産は、管理者等によって格納される。図６は、プログラム資産ＤＢ１３に記憶されるプログラム全体の例を示す図である。図６に示すように、プログラム資産は、プログラム１、プログラム１０、プログラム２、プログラム３、プログラム２０を含む。図６は、５つのプログラムの記述例を模式的に示した例で、プログラム呼出部分およびデータアクセスのみを記述している。

【0031】

重複判定結果ＤＢ１０４は、各プログラムが重複配置を許容するか否かを特定する情報を記憶するデータベースである。例えば、重複判定結果ＤＢ１０４は、各プログラムが複数のプロセスに重複して配置可能であるか否かを示す情報や、重複して配置可能なプログラムの一覧などを記憶する。

【0032】

分析結果ＤＢ１０５は、後述する制御部２０によるプログラム資産の分析結果を記憶するデータベースである。例えば、分析結果ＤＢ１０５は、プログラム資産を示す識別子、分析結果、分析日時などを対応付けて記憶する。

【0033】

制御部１１０は、分析装置１００全体を司る処理部であり、例えばプロセッサなどである。この制御部１１０は、解析部１１１、重複判定部１１２、分析部１１３、提示部１１４を有する。なお、解析部１１１、重複判定部１１２、分析部１１３、提示部１１４は、プロセッサが有する電子回路の一例やプロセッサが実行するプロセスの一例などである。

【0034】

解析部１１１は、プログラム資産内のプログラム間の関係性を解析する処理部である。具体的には、解析部１１１は、プログラム資産を入力として、プログラムの呼び出し関係およびプログラムとデータの関係に基づき、起点となるプログラムと他のプログラムから読み出されるプログラムとを特定する。

【0035】

例えば、図６を例にして説明すると、解析部１１１は、プログラム１、プログラム１０、プログラム２０について、他のプログラムから呼び出されていないため起点と特定する。一方、解析部１１１は、プログラム２とプログラム３については、他のプログラムから呼び出されるので、起点ではなく、他のプログラムから呼び出される非起点プログラムと特定する。そして、解析部１１１は、特定した情報を、記憶部１０２に格納したり、他の処理部に出力したりする。

【0036】

重複判定部１１２は、各プログラムに対して、複数のプロセスに重複して配置することを許容できるか否かを判定する処理部である。具体的には、重複判定部１１２は、解析部１１１により特定された非起点プログラム（呼出先プログラム）が、データを内部に保持するプログラム、または、データを更新するプログラムかを判定する。そして、重複判定部１１２は、これらに該当する場合にそのプログラムを重複配置不可と判定し、これらに該当しない場合にそのプログラムを重複配置可と判定し、その結果を重複判定結果ＤＢ１０４に格納する。

【0037】

例えば、図６を例にして説明すると、重複判定部１１２は、他のプログラムから呼び出されるプログラムと判定されたプログラム２とプログラム３のうち、プログラム３はデータＹに書き込みを行うので重複不可と判定し、プログラム２はデータの書き込みを行わないので重複可と判定する。

【0038】

ここで、図７から図１１を用いて、重複可否の判定例を具体的に説明する。図７は、重複可能と判定される例を説明する図であり、図８から図１１は、重複不可と判定される例を説明する図である。ここでは、ＣＯＢＯＬで記述されたプログラムを例にして説明する。

【0039】

図７の例では、プログラム２は、プログラム１から呼び出されるプログラムであり、呼出元のプログラム１からの入力のみを用いて処理して応答するプログラムである。具体的には、プログラム１は、プログラム２を呼び出すときに入力Ａを指定すると出力Ｂを取得する。プログラム２は、入力Ａが１であれば出力Ｂとして１を返却し、入力Ａが１でなければ出力Ｂとして２を返却する。すわなち、プログラム２は、データを参照するだけであることから、重複可のプログラムと判定される。

【0040】

図８の例では、プログラム３は、プログラム１から呼び出されるプログラムである。具体的には、呼出先のプログラム３は、図７で説明したプログラム２と同様の記述に加えて、データベースであるデータＸに対して更新を行う。すわなち、プログラム３は、データに直接アクセスしてデータ更新を行うプログラムであり、データを更新する構文が記述されていることから、重複不可のプログラムと判定される。

【0041】

図９の例では、プログラム４は、プログラム１から呼び出されるプログラムである。具体的には、プログラム４は、プログラム１からの入力Ａが１の場合に、データＸを更新し、データＸに対してＩＤ＝Ｂを設定する。また、プログラム４は、プログラム１からの入力Ａが１ではない場合に、データＹを更新し、データＹに対してＩＤ＝Ｂを設定する。すなわち、プログラム４は、１つ以上のデータベースを更新するプログラムであることから、重複不可のプログラムと判定される。

【0042】

図１０の例では、プログラム４は、プログラム１から呼び出されるプログラムである。具体的には、プログラム４は、プログラム１からの入力ＡをファイルＡＡに書き込み、ファイルＡＡのデータを、各プログラムがアクセス可能な共有メモリ領域のデータ項目ＢＢに移動させる。すなわち、プログラム４は、ファイルに書き込む構文が記述されるプログラムであり、ファイル側と一体として管理すべきであることから、重複不可のプログラムと判定される。また、プログラム４は、共有メモリの領域を更新する構文が記述されるプログラムでもあり、共有メモリ領域と一体として管理すべきであり、重複不可のプログラムと判定される。

【0043】

図１１の例は、Ｊａｖａ（登録商標）等のオブジェクト指向言語で記述されたプログラムの例である。図１１のプログラムは、ＳＱＬ文などの明示的な記述がないものの、データベースへの参照や更新を行うプログラムである。このように、更新文がないプログラムであっても、データオブジェクトように、複数の処理で共有するデータを更新するプログラムについても、データと一体として管理すべきであり、重複不可のプログラムと判定される。

【0044】

図５に戻り、分析部１１３は、プログラム資産内に各プログラムや各データを、アプリケーションの構造を理解し易くすることができるように分析および分類する処理部である。具体的には、分析部１１３は、特開２０１８－１８１００５号公報の手法を用いて、分類し、サービス部品を生成する。このとき、分析部１１３は、重複判定部１１２により重複不可と判定されたプログラムについては、独立したサービス部品に分類する。

【0045】

例えば、分析部１１３は、起点のプログラムから呼び出し関係を追跡して、プログラムの呼び出し構造全体を作成し、「プログラム群」として定義する。続いて、分析部１１３は、各プログラム群とデータとの関係性から、プログラム群とデータの関係で特に近いものをグループ化した部分集合であるサービス部品候補を生成する。その後、分析部１１３は、複数のサービス部品候補に関連付けられるデータのうち、他のサービス部品候補から更新されるデータを共通データとして抽出し、共通データを含まない複数のサービス部品候補および共通データを、プログラム資産のサービス部品として生成する。

【0046】

ここで、それぞれの処理について説明する。図１２は、プログラムの呼出構造および分類を説明する図である。図１２では、図６のプログラム資産からプログラム群を生成する例を図示している。上記例で説明すると、分析部１１３は、解析部１１１から通知される情報にしたがって、起点としてプログラム１、プログラム１０、プログラム２０を特定する。

【0047】

続いて、分析部１１３は、起点であるプログラム１を起点に呼出構造を作成する。プログラム１は、プログラム２とプログラム３を呼び出す。このことから、プログラム１は、プログラム２、３と合わせて呼び出し構造を保持すると判定できる。したがって、分析部１１３は、プログラム１を起点とするプログラム群１を生成し、プログラム１から追跡できるプログラム２、プログラム３をプログラム群１に分類するが、プログラム３については重複不可と判定されていることから、プログラム群１からは除外する。なお、プログラム２は、重複可能と判定されているので、そのままプログラム群１に分類される。

【0048】

このようにして、分析部１１３は、プログラム１０とプログラム２から構成されるプログラム群１０と、プログラム２０とプログラム２から構成されるプログラム群２０とを生成する。なお、分析部１１３は、プログラム３については重複不可と判定されていることから、いずれのプログラム群にも属さない独立したプログラム群として、プログラム群３を生成する。この結果、分析部１１３は、プログラム群１、プログラム群１０、プログラム群２０、プログラム群３を生成することができる。

【0049】

続いて、分析部１１３は、各プログラム群に対して、各プログラム群がアクセスするデータを対応付ける。具体的には、プログラム群１のプログラム１は、データＸを更新するとともに、データＹを参照する。このため、分析部１１３は、プログラム群１がデータＸを更新しデータ参照するという関係を定義する。このようにして、分析部１１３は、プログラム群１、プログラム群１０、プログラム群２０、プログラム群３それぞれについて、データを対応付ける。

【0050】

これらの結果を図１２に示す。分析部１１３は、図１２の（ａ）に示す呼出関係を基に、図１２の（ｂ）に示すように、プログラム群１がデータＸを更新しデータ参照するという関係などを生成して、記憶部１２や他の処理部に出力する。具体的には、プログラム群１は、データＸを更新し、データＹを参照し、プログラム群３を呼び出す関係を有する。プログラム群１０は、データＹを更新し、プログラム群３を呼び出す関係を有する。プログラム群２０は、データＺを更新し、プログラム群３を呼び出す関係を有する。プログラム群３は、プログラム群１、１０、２０のそれぞれから呼び出され、データＹを更新する関係を有する。

【0051】

なお、出力形式は、これに限定されず、出力先のツール等にあわせて様々な形式を採用できる。例えば、図１２の（ｃ）に示すように、カンマ区切りで関係形成を定義し、プログラム群とデータおよび参照関係を＃read、更新関係を＃writeと言う形で追記することで関係を記述することもできる。例えば、図１２の（ｃ）の１行目は、プログラム群１がデータＸを更新（write）していることを記述している。

【0052】

次に、分析部１１３は、特開２０１３－１４８９８７号公報などのクラスタリング技術を用いて、各プログラム群とデータとの関係性から、プログラム群とデータの関係で特に近いものをグループ化した部分集合であるサービス部品候補を生成する。例えば、分析部１１３は、各データへの入力数が多いほど関係性が強いと判断して、関係性が強いプログラム群とデータとを同一グループとなるように、サービス部品候補を生成する。生成された結果を図１３に示す。図１３は、サービス部品候補の生成結果を説明する図である。

【0053】

図１３に示すように、分析部１１３は、プログラム群１とデータＸとを含むサービス部品候補（ＩＤ＝０１）、プログラム群１０を含むサービス部品候補（ＩＤ＝０２）、プログラム群２０とデータＺを含むービス部品候補（ＩＤ＝０３）、プログラム群３とデータＹを含むービス部品候補（ＩＤ＝０４）の４つのサービス部品候補を生成する。また、分析部１１３は、サービス部品候補ＩＤと部品とを対応付けた二項関係として、「（０１，プログラム群１）、（０１，データＸ）、（０２，プログラム群１０）、（０３，プログラム群１０）、（０３，データＺ）、（０４，プログラム群３）、（０４，データＹ）」なども生成する。その後、分析部１１３は、生成したサービス部品候補を他の処理部に出力する。

【0054】

その後、分析部１１３は、複数のサービス部品候補に関連付けられるデータのうち、他のサービス部品候補から更新されるデータを共通データとして抽出し、共通データを含まない複数のサービス部品候補および共通データを、プログラム資産のサービス部品として生成する。本実施例では、共通データが存在しない場合を例示したので、分析部１１３は、分類したサービス部品の結果として、図１３に示す情報を分析結果ＤＢ１０５に格納する。

【0055】

図５に戻り、提示部１１４は、分析部１１３の分析結果をユーザ等に出力する処理部である。具体的には、提示部１１４は、分析結果ＤＢ１０５に記憶される分析結果を取得し、複数のサービス部品に分類した分析結果を表示する際に、起点となるプログラムや重複不可と判定されたプログラムを、他のプログラムやデータとは異なる形式で表示する。

【0056】

図１４は、分析結果および出力例を説明する図である。図１４に示すように、提示部１１４は、起点のプログラムを縦に長く表示したりすることにより、他のプログラムより大きく出力する。また、提示部１１４は、プロセスごと（パッケージごと）に属するプログラムの色などを変えて表示する。また、提示部１１４は、データ更新等を行うことから独立したプロセスに分類されたプログラム３の色や形を変えることで、他のプログラムとは異なる形式で出力する。なお、提示部１１４は、ソフトウェア地図技術などを用いる場合は、起点のプログラムや重複不可のプログラムの形状について、高さや色を変えることにより、他のプログラムと区別して表示することもできる。

【0057】

［処理の流れ］
図１５は、全体的な処理の流れを示すフローチャートである。図１５に示すように、分析装置１００は、分析処理の開始指示などを受け付けると、プログラム資産内のプログラム間の関係性を解析する（Ｓ１０１）。

【0058】

続いて、分析装置１００は、各プログラムに対して、複数のプロセスに重複して配置することを許容できるか否かを判定する重複判定処理を実行した後（Ｓ１０２）、プログラムの呼び出し構造全体を追跡してプログラム群を生成するプログラム群生成処理を実行する（Ｓ１０３）。

【0059】

その後、分析装置１００は、プログラム群とデータの関係で特に近いものをグループ化した部分集合であるサービス部品候補の生成やサービス部品の抽出を行う部品抽出処理を実行し（Ｓ１０４）、共通データを含まない複数のサービス部品候補および共通データを、プログラム資産のサービス部品として生成した分析結果を提示する（Ｓ１０５）。

【0060】

（重複判定処理）
図１６は、重複判定処理の流れを示すフローチャートである。なお、この処理は、図１５のＳ１０２で実行される処理である。

【0061】

図１６に示すように、重複判定部１１２は、プログラムを取得し（Ｓ２０１）、当該プログラムの記述内容を参照して、データやＤＢを更新する構文があるか否かを判定する（Ｓ２０２）。ここで、重複判定部１１２は、データやＤＢを更新する構文がある場合（Ｓ２０２：Ｙｅｓ）、当該プログラムを重複不可として分類する（Ｓ２０３）。

【0062】

一方、重複判定部１１２は、データやＤＢを更新する構文がないものの（Ｓ２０２：Ｎｏ）、ファイルを書き込む構文がある場合（Ｓ２０４：Ｙｅｓ）、当該プログラムを重複不可として分類する（Ｓ２０３）。

【0063】

また、重複判定部１１２は、ファイルを書き込む構文がないものの（Ｓ２０４：Ｎｏ）、共有メモリの領域を更新する構文がある場合（Ｓ２０５：Ｙｅｓ）、当該プログラムを重複不可として分類する（Ｓ２０３）。

【0064】

そして、重複判定部１１２は、共有メモリの領域を更新する構文もない場合（Ｓ２０５：Ｎｏ）、当該プログラムを重複可として分類する（Ｓ２０６）。その後、重複判定部１１２は、未判定のプログラムが存在する場合（Ｓ２０７：Ｎｏ）、Ｓ２０１以降を繰り返し、全プログラムについて判定が終了すると（Ｓ２０７：Ｙｅｓ）、処理を終了する。

【0065】

（プログラム群生成処理）
図１７は、プログラム群生成処理の流れを示すフローチャートである。なお、この処理は、図１５のＳ１０３で実行される処理である。

【0066】

図１７に示すように、分析部１１３は、起点のプログラムを取得し（Ｓ３０１）、起点のプログラムから呼び出される呼出先のプログラムを取得する（Ｓ３０２）。

【0067】

続いて、分析部１１３は、呼出先のプログラムが重複可能なプログラムの場合（Ｓ３０３：Ｙｅｓ）、呼出先のプログラムを起点プログラムと同一のプログラム群に含める（Ｓ３０４）。一方、分析部１１３は、呼出先のプログラムが重複不可能なプログラムの場合（Ｓ３０３：Ｎｏ）、呼出先のプログラムと起点のプログラム群との二項関係を生成する（Ｓ３０５）。

【0068】

そして、分析部１１３は、追跡していない呼出先のプログラムが存在する場合（Ｓ３０７：Ｎｏ）、Ｓ３０２以降を繰り返す。一方、分析部１１３は、全ての呼出先のプログラムについて追跡が完了し（Ｓ３０７：Ｙｅｓ）、未処理の起点のプログラムが存在する場合（Ｓ３０８：Ｎｏ）、Ｓ３０１以降を繰り返し、未処理の起点のプログラムが存在しない場合（Ｓ３０８：Ｙｅｓ）、処理を終了する。

【0069】

［効果］
上述したように、分析装置１００は、データに対して読み込み処理しかしないプログラムに対しては、多くの箇所（プロセス）からデータを読み込んでも問題が少なく、プロセス内部にプログラムを含めれば、プロセス内部の処理が早いと判定し、重複可能と判定することができる。また、分析装置１００は、データに対して書込み処理をするプログラムに対しては、多くの箇所（プロセス）からデータを書き込むと他の処理が待たされることを優先し、重複不可能と判定することができる。

【0070】

したがって、分析装置１００は、資産を分割するために、プログラムを重複して良いものと、重複してはいけないものを明示できることで、利用しやすい分割案を提示することができる。この結果、分析装置１００は、理解し易い形式でアプリケーションの構造を提示することができる。

【実施例2】

【0071】

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。

【0072】

［データや数値等］
上記実施例で用いたプログラム、プロセス、サービス部品、データの数等は、あくまで一例であり、任意に変更することができる。また、各処理の順序も矛盾のない範囲内で適宜変更することができる。

【0073】

［プログラム解析］
上記実施例で説明した呼び出し関係やデータへの読み出し関係を取得する手法としては、パーサなどの公知のプログラム解析技術を採用することができる。

【0074】

［システム］
上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

【0075】

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散や統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

【0076】

さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

【0077】

［ハードウェア］
図１８は、ハードウェア構成例を説明する図である。図１８に示すように、分析装置１０は、通信装置１００ａ、ＨＤＤ（Hard Disk Drive）１００ｂ、メモリ１００ｃ、プロセッサ１００ｄを有する。また、図１８に示した各部は、バス等で相互に接続される。

【0078】

通信装置１００ａは、ネットワークインタフェースカードなどであり、他の装置との通信を行う。ＨＤＤ１００ｂは、図２に示した機能を動作させるプログラムやＤＢを記憶する。

【0079】

プロセッサ１００ｄは、図５に示した各処理部と同様の処理を実行するプログラムをＨＤＤ１００ｂ等から読み出してメモリ１００ｃに展開することで、図５等で説明した各機能を実行するプロセスを動作させる。例えば、このプロセスは、分析装置１００が有する各処理部と同様の機能を実行する。具体的には、プロセッサ１００ｄは、解析部１１１、重複判定部１１２、分析部１１３、提示部１１４等と同様の機能を有するプログラムをＨＤＤ１０ｂ等から読み出す。そして、プロセッサ１０ｄは、解析部１１１、重複判定部１１２、分析部１１３、提示部１１４等と同様の処理を実行するプロセスを実行する。

【0080】

このように、分析装置１００は、プログラムを読み出して実行することで資産管理方法を実行する情報処理装置として動作する。また、分析装置１００は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、分析装置１００によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。

【符号の説明】

【0081】

１００ 分析装置
１０１ 通信部
１０２ 記憶部
１０３ プログラム資産ＤＢ
１０４ 重複判定結果ＤＢ
１０５ 分析結果ＤＢ
１１０ 制御部
１１１ 解析部
１１２ 重複判定部
１１３ 分析部
１１４ 提示部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】