(58)【調査した分野】(Int.Cl.,DB名)
商品に対する申込内容についての適否を前記商品の属性に基づいて判定するための判定規則が既存の商品ごとに記述されたソースコードを入力して抽象構文木を生成する構文解析部と、
生成された抽象構文木を利用してネスト構造を解析することで、前記既存の商品ごとにおける前記属性間の順序関係を設定するネスト構造解析部と、
設定された前記属性間の順序関係に基づいて、前記ソースコードに記述される属性ごとの優先順を設定する優先順設定部と、
前記属性ごとに設定された優先順と、前記既存の商品の属性の内容と新商品の属性の内容との一致状態に基づいて、前記既存の商品のうちから新商品に最も類似する類似商品を判定する類似商品判定部と、
を備えることを特徴とする情報処理装置。
前記ソースコードにおいて前記類似商品の判定規則が記述されている箇所に基づいて、前記新商品の判定規則の追加のために前記ソースコードにおいて変更すべき内容を判定する変更判定部をさらに備える、
ことを特徴とする請求項1に記載の情報処理装置。
商品に対する申込内容についての適否を前記商品の属性に基づいて判定するための判定規則が既存の商品ごとに記述されたソースコードを入力して抽象構文木を生成する構文解析ステップと、
生成された抽象構文木を利用してネスト構造を解析することで、前記既存の商品ごとにおける前記属性間の順序関係を設定するネスト構造解析ステップと、
設定された前記属性間の順序関係に基づいて、前記ソースコードに記述される属性ごとの優先順を設定する優先順設定ステップと、
前記属性ごとに設定された優先順と、前記既存の商品の属性の内容と新商品の属性の内容との一致状態に基づいて、前記既存の商品のうちから新商品に最も類似する類似商品を判定する類似商品判定ステップと、
を備えることを特徴とする情報処理方法。
【発明を実施するための形態】
【0017】
<第1の実施形態>
[ソースコード処理装置の構成]
図1は、本発明の実施形態における情報処理装置であるソースコード処理装置100の構成例を示している。なお、本実施形態におけるソースコード処理装置100は、顧客が金融商品を契約するにあたって、顧客の申込内容がその金融商品の契約条件に適合するか否かを判定(審査)するプログラムのソースコードを対象として処理する。
【0018】
本実施形態のソースコード処理装置100は、ソースコード記憶部101、構文解析部102、ネスト構造解析部103、優先順設定部104、類似商品判定部105、新商品データ記憶部106、変更判定部107、表示部108、ソースコード変更部109および操作部110を備える。
【0019】
ソースコード記憶部101は、ソースコードを記憶する。このソースコードは、上記のように顧客が金融商品(以下、単に「商品」という)を契約するにあたって、顧客の申込内容についての適否を商品の契約条件を形成する属性に基づいて判定するためプログラムに対応するものである。つまり、このソースコードは、商品に対する申込内容についての適否を商品の契約条件を形成する属性に基づいて判定するためのチェックルール(判定規則)が既存の商品ごとに記述されたものである。なお、本実施形態において、このソースコードを記述するためのプログラム言語については特に限定されるものではない。
【0020】
構文解析部102は、ソースコード記憶部101に記憶されているソースコードを入力して抽象構文木を生成する。
【0021】
ネスト構造解析部103は、構文解析部102により生成された生成された抽象構文木を利用してネスト構造を解析することで、既存の商品ごとにおける属性間の順序関係を設定する。
【0022】
優先順設定部104は、ネスト構造解析部103により設定された属性間の順序関係に基づいて、前記ソースコードに記述される属性ごとの優先順を設定する。そのうえで、第1の実施形態における優先順設定部104は、ネスト構造として解析された属性間の順序関係についての推移律に基づいて優先順を設定する。
【0023】
類似商品判定部105は、属性ごとに設定された優先順と、既存の商品の属性の内容と新商品の属性の内容との一致状態に基づいて、既存の商品のうちから新商品に最も類似する類似商品を判定する。具体的に、第1の実施形態における類似商品判定部105は、優先順が高い方から順に、新商品と既存の商品の各々とで属性の内容が不一致となるまで属性の内容を比較した結果、内容が一致する属性の数が最も多い既存の商品を類似商品として判定する。
【0024】
新商品データ記憶部106は、新商品に関する契約条件を示す新商品データを記憶する。なお、ソースコード記憶部101と新商品データ記憶部106に対応するハードウェアは、例えばHDD(Hard Disc Drive)やフラッシュメモリなどとすることができる。また、ソースコード記憶部101と新商品データ記憶部106としてのハードウェアは共通とすることができる。
【0025】
変更判定部107は、ソースコードにおいて類似商品のチェックルールが記述されている箇所に基づいて、新商品のチェックルールの追加のためにソースコードにおいて変更すべき内容を判定する。
本実施形態の変更判定部107は、ソースコードにおいて変更すべき内容として、ソースコードにおいて変更すべき箇所(変更箇所)と、この変更箇所における記述の変更内容(記述変更内容)を判定する。ここで変更箇所とはソースコードにおける行(ステップ)、または行内の位置などである。また、記述変更内容とは、単語やステップの追加または削除などである。
【0026】
表示部108は、変更判定部107により判定されたソースコードにおいて変更すべき内容を変更判定部107の制御に応じて表示する。
なお、変更判定部107が例えば変更箇所のみを判定し、表示部108にその変更箇所が示されるように表示させることも考えられる。
【0027】
エンジニア(ユーザ)は、表示部108に表示された内容を確認して、新商品に対応するチェックルールが反映されるようにソースコードを変更するための操作を操作部110に対して行う。
ソースコード変更部109は、操作部110に対して行われたソースコード変更のための操作に応じてソースコード記憶部101に記憶されているソースコードの内容を変更する。
【0028】
操作部110は、ソースコード処理装置100をエンジニアが操作するための操作デバイスを一括して示したもので、例えばキーボードやマウスなどを含む。
【0029】
[ソースコード変更の基本概念]
続いて、本実施形態における新商品に応じたソースコード変更の基本概念について説明する。なお、本実施形態においては、金融商品を対象とした商品申込みに関する審査業務に対応する場合を例として説明するが、対象とする商品は金融商品には限定されるものではない。
図2(a)には、新商品の契約条件(仕様)の一例が示されている。この新商品の契約条件の内容は、「商品タイプ」が「国債」、「商品ID」が「90」、「発売年」が「2012年」、「償還期間」が「10年」となっている。
なお、上記の契約条件における「商品タイプ」、「商品ID」、「発売年」、「償還期間」などの項目は、本実施形態においては、商品の属性として扱われる。なお、
図2においては便宜上、上記の4つの属性を例示しているが、さらに多くの属性が商品ごとに設定されてよい。
【0030】
本実施形態において、新商品に応じたソースコードの変更を行うにあたっては、既存の商品のうちから、新商品に類似した類似商品を探し出す。そして、ソースコードにおいてこの類似商品に対応するチェックルールが記述された部分の内容をコピーし、このコピーした内容を新商品の契約内容に対応させて変更する。
【0031】
図2(b)は、新商品に類似するものとして抽出された類似商品の契約条件を示している。この類似商品の契約条件は、「商品タイプ」の属性が「国債」、「商品ID」の属性が「75」、「発売年」の属性が「2012年」、「償還期間」の属性が「5年」となっている。
【0032】
図2(c)は、
図3(b)の類似商品に対応してソースコードから抽出したチェックルールの内容例を示している。
図2(c)によれば、類似商品のチェックルールは、「取引機関が「窓口販売」である場合はエラー」、「領域払込が「3回払い」である場合はエラー」、「取引機関が「A銀行」かつ料金払込が「2回払い」である場合はエラー」・・・・というように、エラー(不適合)となる条件が示される。なお、
図2(c)においては、理解のためにチェックルールの内容を記載しているが、ソースコードにおいては、この内容が所定のプログラミング言語により記述されている。
【0033】
そして、新商品に対応しては、
図2(c)のチェックルールの内容をコピーし、この内容を新商品の契約条件に合わせて変更する。
図2(d)には、新商品に対応して
図2(c)の内容を変更した結果として、2番目と3番目の項目の「領域払込が「3回払い」はエラー」、「取引機関が「A銀行」かつ料金払込が「2回払い」はエラー」の内容を削除している。
そして、本実施形態では、例えば
図2(d)に示した変更をソースコードに反映させる。これにより、変更後のソースコードによって、新商品の契約申込に対する適否の判定(審査)を行うことができる。
【0034】
ここで、新商品に対応する類似商品を特定するにあたっては、単に内容が一致する属性の数に依存するのではなく、重要度の高い属性ができるだけ数多く一致していることが必要である。
この点について、
図3を参照して説明する。
図3(a)は、新商品の契約条件の例を示し、
図3(b)、(c)、(d)は、それぞれ、
図3(a)の新商品に対する類似商品候補α、β、γの契約条件の例を示している。
この場合において、
図3(b)に示す類似商品候補αは、「商品タイプ」の属性と「償還期間」の属性の内容がそれぞれ「国債」と「10年」であり、
図3(a)の新商品と一致している。
また、類似商品候補βは、
図3(c)に示すように、「商品タイプ」の属性と「購入可能者」の属性の内容がそれぞれ「国債」と「個人」であり、
図3(a)の新商品と一致している。
また、類似商品候補γは、
図3(d)に示すように、「発売年」の属性と「償還期間」の各属性の内容が「2012年」と「10年」で、
図3(a)の新商品と一致している。
【0035】
ここで、
図3(b)、(c)、(d)に示される類似商品候補α、β、γは、いずれも、2つの属性の内容が新商品と一致している。ただし、その2つの属性の組み合わせが類似商品候補α、β、γとで互いに異なる。
前述のように、類似商品は、重要度の高い属性ができるだけ数多く新商品と一致していることが必要である。したがって、これらの類似商品候補α、β、γの新商品に対する類似性の高さは、新商品と内容が一致する属性の組み合わせにより異なる。
この場合において、例えば、最も重要度が高い属性は「商品タイプ」であり、次いで重要度が高い属性は「償還期間」である。したがって、類似商品候補α、β、γのうち、新商品と最も類似しているものは、
図3(b)のように、「商品タイプ」と「償還期間」の属性の組み合わせの内容が新商品と一致している類似商品候補αということになる。つまり、この場合は、類似商品候補αが類似商品として選択される。
【0036】
例えば、エンジニアが上記のように商品の属性の重要性を考慮して新商品の類似商品を特定しようとするには、十分な商品の知識が必要であるが、このような人材を確保するのは難しい。また、このような人材が確保できたとしても、既存の商品の数は膨大であるために、類似商品を最終的に特定するまでには相当の時間がかかってしまう。
そこで、本実施形態のソースコード処理装置100は、以降説明するように新商品に応じた類似商品を自動で判定する。
【0037】
[ソースコードの例]
図4は、ソースコード処理装置100のソースコード記憶部101に記憶されるソースコード120の例を示している。この図に示すソースコード120は、3つの既存の商品のチェックルールが記述されている例である。なお、ソースコード120にそのチェックルールが記述される既存の商品の数は特に限定されるものではなく、さらに多数であってよい。
図4のソースコード120にチェックルールが記述されている3つの商品とは、それぞれ、「ID(商品ID)」の属性について「ID=13」、「ID=10」、「ID=20」のものである。
図4におけるブロックBK1は、「ID=13」の商品に対応する複数のチェックルールが記述されたブロックを示す。
また、
図5と
図6には、それぞれ、
図3と同じソースコード120が示されている。
図5におけるブロックBK2は、「ID=10」の商品に対応する複数のチェックルールが記述されたブロックを示す。
図6におけるブロックBK3は、「ID=20」の商品に対応する複数のチェックルールが記述されたブロックを示す。
【0038】
[ソースコード処理装置の処理例]
以降、ソースコード処理装置100が類似商品判定と、ソースコードにおいて変更すべき内容の判定のために実行する処理の一例について説明する。
まず、構文解析部102は、
図4〜
図6に示した内容のソースコード120をソースコード記憶部101から読み込む。そして、この読み込んだソースコード120を構文解析することにより、抽象構文木を生成する。
【0039】
図7は、
図4〜
図6に示した内容のソースコード120を構文解析して生成された抽象構文木200の例を示している。
図7において、ノードnd1がルートである。そのうえで、ノードnd2〜nd11を含む木構造部分は、
図4に示したブロックBK1に対応する。
また、ノードnd2、nd4およびnd12〜nd20を含む木構造部分は、
図5のブロックBK2に対応する。
また、ノードnd21〜nd27を含む木構造部分は、
図6のブロックBK3に対応する。
【0040】
次に、ネスト構造解析部103は、
図7に示すように生成された抽象構文木200を入力して、そのネスト構造を解析する。ネストとは、ソースコードにおけるブロックの入れ子の構造をいう。
【0041】
図7の抽象構文木200の場合のネスト構造は、ブロックBK1、BK2、BK3に対応する3つの木構造部分に分けられる。これに応じて、ネスト構造解析部103は、ブロックBK1、BK2、BK3ごとのネスト構造に対応するネスト情報を生成し、これらのネスト情報をネスト情報テーブルとして出力する。
【0042】
図8(a)は、
図7の抽象構文木200に対応して出力されるネスト情報テーブル300の例を示している。
この図に示すネスト情報テーブル300は、ネスト情報IDに対してネスト情報が対応付けられた構造である。ネスト情報ID=1はブロックBK1に対応する。ネスト情報ID=2はブロックBK2に対応する。ネスト情報ID=3はブロックBK1に対応する。
ネスト情報を生成するにあたり、ネスト構造解析部103は、深さ優先探索を行うことで、ネストが浅いほうのIF文(条件文)において判定に用いられる属性が先で、ネストが深いほうのIF文において判定に用いられる属性が後となるように属性間の順序関係を設定する。
【0043】
例えば
図7のブロックBK1の木構造部分について深さ優先探索によりノードを探索していくことによっては、ネスト構造解析部103は、ネストの最も浅いIF文において判定に用いられる属性はノードnd3において示される「商品タイプ」であることを認識する。また、ネスト構造解析部103は、次に深いネストのIF文において判定に用いられる属性は、ノードnd6において示される「償還期間」であることを認識し、さらに次に深いネストのIF文において判定に用いられる属性は、ノードnd8において示される「ID」と「購入者」であることを認識する。
【0044】
これにより、ネスト構造解析部103は、
図8(a)においてネスト情報ID=1のネスト情報として示すように、「商品タイプ>償還期間>ID|購入者」という内容のネスト情報を生成する。なお、上記の順序関係を示す式において「|」の記号は、一つの条件式において複数の属性が存在していることを示す。つまり、「|」の記号に対して前後に記述される2つの項については、論理積と論理和のいずれも問わないということを意味する。
したがって、ブロックBK1における属性の順序関係は、「商品タイプ」に次いで「償還期間」となり、その次は「ID」と「購入者」が並列になるというものである。
【0045】
また、ネスト構造解析部103は、ブロックBK2に対応する木構造部分を深さ優先で探索することにより、ネスト構造解析部103は、
図8(a)においてネスト情報ID=2のネスト情報として示すように、「商品タイプ>償還期間>購入金額」という内容のネスト情報を生成する。つまり、ブロックBK2における属性の順序関係は、「商品タイプ」に次いで「償還期間」となり、その次は、「購入金額」になるというものである。
【0046】
また、ネスト構造解析部103は、ブロックBK3に対応する木構造部分を深さ優先で探索することにより、
図8(a)においてネスト情報ID=3のネスト情報として示すように、「商品タイプ>ID|販売所」という内容のネスト情報を生成する。つまり、ブロックBK3における属性の順序関係は、「商品タイプ」に次いで、「ID」と「販売所」が並列になるというものである。
【0047】
次に、優先順設定部104は、
図8(a)に示すネスト情報テーブル300に基づいて、ソースコードのIF文に出現する属性ごとに優先順を設定する。ここで、ネスト情報テーブル300において、ソースコードのIF文に出現するすべての属性が抽出され、ブロックごとに対応してその順序関係が設定されている。
【0048】
そこで、優先順設定部104は、ネスト情報テーブル300におけるネスト情報ごとにおいて示される属性の順序関係に推移律を適用して、ネスト情報テーブル300において示されているすべての属性ごとの優先順を設定する。これにより、ソースコードのIF文に出現するすべての属性ごとに優先順が設定されたことになる。
なお、
図8(a)に示すネスト情報の各々は、ブロックごとに対応するものであるが、1つのブロックは、1つの商品に対応するチェックルールに対応する。したがって、ネスト情報の各々は、対応の商品における属性の順序関係を示している。
【0049】
優先順設定部104は、設定した優先順を示す優先順情報を出力する。
図8(b)は、
図8(a)のネスト情報テーブル300に基づいて設定した優先順を示す優先順情報400の例である。
この
図8(b)に示す優先順情報400においては、「商品タイプ」の属性が最も優先順が高く、次いで、「償還期間」の属性の優先順が高い。また、「償還期間」に次いでは、「購入者」、「ID」、「購入金額」、「販売所」の4つの属性が並列に同じ優先順である。
【0050】
図8(b)の優先順情報400に示される優先順は、ネストが浅いIF文に出現している属性のほうが高くなっている。ソースコード120においては、複数の商品で共通して使用することが多い属性を含むIF文ほどネストが浅くなる。つまり、IF文に含まれる属性は、そのIF文のネストが浅いほど重要度が高いということになる。この点に着目し、優先順設定部104は、ネストが浅いIF文に含まれる属性の優先順が高くなるように優先順の設定を行うものである。
【0051】
次に、類似商品判定部105は、ソースコード120においてチェックルールが記述される「ID=13」、「ID=10」、「ID=20」の既存の商品の属性の内容を、
図8(b)に示される優先順情報400が示す優先順にしたがってソートする。類似商品判定部105は、このソート結果を、既存商品属性テーブルとして生成する。
【0052】
図9(a)の既存商品属性テーブル500は、「ID=13」、「ID=10」、「ID=20」の商品ごとの属性の内容を、
図8(b)に示される優先順情報が示す優先順にしたがってソートした結果を示している。
【0053】
この既存商品属性テーブル500においては、最も左の列の属性が優先順が最も高く、右となるのに応じて低くなっていく。なお、優先順が同じで並列となった属性については、所定規則にしたがって配列順を決定してソートすればよい。
【0054】
また、類似商品判定部105は、
図9(b)に示す新商品属性テーブル600も生成する。このために、類似商品判定部105は、新商品データ記憶部106から新商品データを読み出す。そして、類似商品判定部105は、読み出した新商品データが示す新商品の属性の内容を、
図8(b)の優先順情報400が示す優先順にしたがってソートすることで、新商品属性テーブル600を生成する。
【0055】
次に、類似商品判定部105は、既存の商品ごとに、優先順が高いほうの属性から順に、新商品属性テーブル600が示す属性の内容との比較を行っていく。この際、類似商品判定部105は、既存の商品ごとの比較の処理について、不一致の結果が得られた段階で終了させる。
【0056】
具体的に、
図9(a)と
図9(b)において優先順が最も高い属性は「商品タイプ」である。
そこで、類似商品判定部105は、まず、
図9(a)の1行目の「ID=10」の商品について、「商品タイプ」の内容を
図9(b)と比較する。この場合、「商品タイプ」の内容は、互いに「国債」で一致する。
【0057】
そこで、類似商品判定部105は、優先順が2番目の「償還期間」の属性の内容を
図9(a)の1行目と
図9(b)とで比較する。この場合にも、「償還期間」の属性の内容は「10年」で一致している。
【0058】
そこで、類似商品判定部105は、さらに。その右側に配列されている次の優先順の「購入者」の属性の内容を
図9(a)の1行目と
図9(b)とで比較する。この段階で、「購入者」の属性の内容は、
図9(a)の1行目が「法人、個人」であるのに対して、
図9(b)は「法人」のみであることから、その内容が不一致となる。そこで、類似商品判定部105は、
図9(a)の1行目の商品についての属性内容の比較を終了させる。
【0059】
次に、類似商品判定部105は、
図9(a)の2行目の「ID=13」の商品について、「商品タイプ」の内容を
図9(b)と比較する。この場合、「商品タイプ」の属性の内容は、互いに「国債」で一致する。
【0060】
そこで、類似商品判定部105は、優先順が2番目の「償還期間」の属性の内容を
図9(a)の2行目と
図9(b)とで比較する。この場合、「償還期間」の属性の内容は、
図9(a)の2行目が「5年」であるのに対して、
図9(b)は「10年」であることから、その内容が不一致となる。そこで、類似商品判定部105は、
図9(a)の2行目の商品についての属性内容の比較を終了させる。
【0061】
次に、類似商品判定部105は、
図9(a)の3行目の「ID=20」の商品について、「商品タイプ」の内容を
図9(b)と比較する。この場合、「商品タイプ」の内容は、互いに「国債」で一致する。この場合、「商品タイプ」の属性の内容は、
図9(a)の3行目が「地方債」であるのに対して、
図9(b)は「国債」であることから、その内容が不一致となる。そこで、類似商品判定部105は、
図9(a)の3行目の商品についての属性内容の比較を終了させる。
【0062】
図9(c)は、上記のように比較を行った結果を既存商品属性テーブル500に反映させたものである。これまでの比較結果から、類似商品判定部105は、
図9(a)の1行目の「ID=10」の商品は、新商品と内容が一致した属性の数が「2」であることを認識する。また、
図9(a)の2行目の「ID=13」の商品は、新商品と内容が一致した属性の数が「1」であることを認識する。また、
図9(a)の3行目の「ID=20」の商品は、新商品と内容が一致した属性の数が「0」であることを認識する。
【0063】
上記のように認識された属性の数が多い既存の商品ほど、新商品との間で優先順が高い(つまり、重要度が高い)属性を多く共有していることになるので、新商品との類似度が高いと見てよい。そこで、類似商品判定部105は、例えば上記のように既存の商品ごとに認識した属性の数を、
図9(c)の最も右の列に示すように、類似度として求める。つまり、
図9(a)の1行目の「ID=10」の商品の類似度は「2」であり、2行目の「ID=13」の商品の類似度は「1」であり、3行目の「ID=20」の商品の類似度は「0」である。
【0064】
そして、類似商品判定部105は、このように求められた類似度が最大値の商品を類似商品として判定する。
図9(c)の場合であれば、類似商品判定部105は、1行目における「ID=10」の商品を類似商品として判定する。
【0065】
変更判定部107は、類似商品判定部105による類似商品の判定結果に基づき、新商品のチェックルールの追加のためにソースコード120において変更すべき内容を判定する。
このために、変更判定部107は、類似商品判定部105により類似商品として判定された商品のID(商品ID)を入力する。また、ソースコード記憶部101に記憶されているソースコード120を読み出す。そして、変更判定部107は、類似商品として判定された商品のIDを利用して、ソースコード120において類似商品のチェックルールが記述されたブロックを探索する。
【0066】
具体的に、
図9(c)にて類似商品であると判定された商品は、「ID=10」の商品である。この「ID=10」の商品のチェックルールが記述されたブロックをソースコード120から探索するために、変更判定部107は、例えばIF文に「ID=10」を含むブロックを探索する。この結果、変更判定部107は、「ID=10」の商品のチェックルールが記述されたブロックとして、
図5のブロックBK2を探索する。
【0067】
次に、変更判定部107は、新商品データ記憶部106から新商品データを読み出す、そして、変更判定部107は、ブロックBK2において記述されるチェックルールと新商品データにおいて示される新商品のチェックルールとの差分を認識する。この場合において、変更判定部107は、差分として、ブロックBK2のチェックルールにおいて、新商品の商品IDのみが記述されていないことを認識する。
【0068】
そこで、この場合の変更判定部107は、上記のように認識した差分にしたがって、ブロックBK2においてIF文にIDの属性を含む、「IF ID = 10」の行が変更箇所であると判定する。
【0069】
さらに、本実施形態の変更判定部107は、変更箇所における記述変更内容も判定する。この場合には、「IF ID = 10」のIF文に対して新商品の「ID=30」を追加すべきであるため、変更判定部107は、変更箇所「IF ID = 10」の行について、「IF ID = 10 OR 30」と、「OR 30」を末尾に追加するように記述を変更すべきであると判定する。
【0070】
そして、変更判定部107は、上記の判定結果(変更箇所と記述変更内容)を表示部108に表示させる。
図10は、表示部108に表示される判定結果の内容が示されている。この図に示すように、表示部108には、例えば、ソースコード120が示される。そのうえで、このソースコード120における変更箇所である「IF ID = 10」のIF文において、その後ろに「OR 30」を追加して表示し、この「OR 30」が記述変更内容であることを示すハイライト表示indにより強調する。
【0071】
この
図10に示す表示を見たエンジニアは、例えば、このように表示された内容を確認したうえで、新商品のチェックルールが反映されるようにソースコード120を書き換えるための操作を操作部110に対して行う。この操作に応じてソースコード変更部109は、ソースコード記憶部101に記憶されているソースコード120を変更する。
このように、本実施形態においては、例えばエンジニアが十分な商品知識を有していなくとも、ソースコード処理装置が新商品に対応する類似商品を自動で判定する。そして、類似商品の判定結果に基づいて、ソースコード120において変更すべき内容を判定してエンジニアに通知することができる。なお、変更判定部107の判定結果の表示態様については特に
図10に示したものに限定されない。
【0072】
[処理手順例]
図11のフローチャートは、ソースコード処理装置100が実行する処理手順例を示している。
まず、構文解析部102は、ソースコード記憶部101からソースコード120を読み込む(ステップS101)。次に、構文解析部102は、読み込んだソースコード120の構文解析を行って、抽象構文木200を生成する(ステップS102)。
【0073】
ネスト構造解析部103は、ステップS102により生成された抽象構文木200を利用して、ブロックごと(つまり、既存の商品ごと)の属性の順序関係を示すネスト情報を生成する(ステップS103)。
【0074】
優先順設定部104は、ステップS103により生成されたブロックごとのネスト情報から、ソースコード120において記述されているすべての属性についての優先順を設定する(ステップS104)。
【0075】
類似商品判定部105は、ステップS104により設定された属性ごとの優先順と、既存の商品ごとの属性の内容と、新商品データ記憶部106から読み出した新商品データが示す新商品の属性の内容とに基づいて、既存の商品のうちから、新商品に類似する類似商品を1つ判定する(ステップS105)。
【0076】
変更判定部107は、ステップS105により判定された類似商品の商品IDと、新商品データとに基づいて、ソースコード120における変更箇所と、その変更箇所における記述変更内容を判定する(ステップS106)。
そして、変更判定部107は、判定結果である変更箇所と記述変更内容をソースコードとともに表示部108に表示させる(ステップS107)。
【0077】
そして、ソースコード変更部109は、操作部110に対してエンジニアが行ったソースコード120を変更するための操作に応じて、ソースコード記憶部101に記憶されているソースコード120を変更する(ステップS108)。
【0078】
図12のフローチャートは、類似商品判定部105が
図11のステップS105として実行する類似商品判定のための処理手順例を示している。
【0079】
まず、類似商品判定部105は、
図9(b)に示した新商品属性テーブル600を予め生成する(ステップS201)。つまり、類似商品判定部105は、新商品の属性を、
図11のステップS104により設定された優先順に対応させてソートする。
【0080】
次に、類似商品判定部105は、
図9(a)、(c)に示した既存商品属性テーブル500における行番号を示す変数nに「1」を代入する(ステップS202)。
【0081】
次に、類似商品判定部105は、既存商品属性テーブル500におけるn行目を選択し(ステップS203)、さらに、優先順を示す変数mに「1」を代入する(ステップS204))。
そのうえで、類似商品判定部105は、既存商品属性テーブル500のn行目と新商品属性テーブル600において優先順がm番目の属性の内容を比較する(ステップS205)。
【0082】
類似商品判定部105は、ステップS205による比較結果として、両者の属性の内容が一致したか否かについて判定する(ステップS206)。ここで、一致したのであれば(ステップS206−YES)、類似商品判定部105は、変数mをインクリメントして(ステップS207)、ステップS205に戻る。これにより、次の優先順の属性の内容についての比較が引き続き行われる。
【0083】
これに対して、内容が一致していない場合(ステップS206−NO)、類似商品判定部105は、既存商品属性テーブル500のn行目の商品についての類似度Dに対して、変数mの値を代入する(ステップS208)。つまり、類似商品判定部105は、
図9の説明にしたがって、内容が一致していたと判定された属性の数に応じた値を類似度Dとして求めるものである。
【0084】
次に、類似商品判定部105は、変数nが最大値であるか否かについて判定する(ステップS209)。
図9との例の対応では、変数nの最大値は「3」である。
変数nが最大値ではない場合には(ステップS209−NO)、まだ、属性内容の比較を行っていない既存商品属性テーブル500の行が残っている。そこで、この場合、類似商品判定部105は、変数nをインクリメントしたうえで(ステップS210)、ステップS203に戻ることで、既存商品属性テーブル500における次の行を対象として属性内容の比較を行う。
一方、変数nが最大値である場合には(ステップS209−YES)、既存商品属性テーブル500のすべての行について属性内容の比較を行ったことになる。そこで、この場合の類似商品判定部105は、類似度Dが最大値の行に対応する既存の商品を類似商品として判定する(ステップS211)
【0085】
<第2の実施形態>
[ネスト構造解析部、優先順設定部、類似商品判定部の動作例]
次に、第2の実施形態について説明する。なお、第2の実施形態におけるソースコード処理装置100の全体構成としては、
図1と同様でよい。また、第2の実施形態におけるソースコード処理装置100が実行する処理手順の全体としては、
図11と同様でよい。
【0086】
第1の実施形態と第2の実施形態においては、属性に対する優先順の設定手法が異なる。第1の実施形態においては、ネスト構造解析部103により解析されたブロックごとの属性の順序関係に対して推移律を適用して属性ごとの優先順を設定した。
これに対して、第2の実施形態では、ネスト構造解析部103は、ネストの深さによるのではなく、各ネスト情報における属性に重み付け値を設定し、この重み付け値に応じてブロックごとの属性の順序関係を設定する。そして、優先順設定部104は、このネスト情報ごとの属性の重み付け値に基づき、属性ごとの優先順を設定する。さらに、類似商品判定部105は、新商品と既存の商品の各々とで内容が一致する属性に設定された前記重み付け値に基づいて求めた類似度が最も高い既存の商品を類似商品として判定する。
【0087】
[属性に対する重み付け値の設定例]
図13(a)、(b)は、それぞれ、第2の実施形態におけるネスト構造解析部103がネスト情報を生成する際の属性に対する重み付け値の設定例を示している。
まず、
図13(a)においては、ソースコード120における同じ階層において、条件文L1、L2、L3の3つの条件文(IF文)が記述されている。このうち、条件文L1は「ID(商品ID)」の属性を含んでいるが、条件文L2、L3は、いずれも「商品タイプ」の属性を含んでいる。つまり、「商品タイプ」の属性については、同じ階層において複数の条件文に含まれている。
【0088】
このように、同じ階層において複数の条件文に同じ属性が含まれている場合、この属性は重要度が高いということがいえる。そこで、同じ階層において複数の条件文に同じ属性が含まれている場合、ネスト構造解析部103は、この属性の重み付け値を大きく変更するように設定する。
【0089】
一例として、
図13(a)の場合において、重み付け値のデフォルトの値は「0.4」であるとする。
図13(a)のソースコード120において、同じ階層で「ID」の属性を含むのは条件文L1のみであるから、ネスト構造解析部103は、「ID」の属性に対してデフォルトとしての「0.4」の重み付け値を設定する。
【0090】
これに対して、条件文L2、L3の2つは、ともに同じ階層であって、かつ、同じ「商品タイプ」の属性を含んでいる。そこで、ネスト構造解析部103は、「商品タイプ」の属性については、デフォルトの「0.4」より大きい重み付け値として、例えば、「0.4」の2倍の「0.8」を設定する。
なお、このように重み付け値を大きく変更するように設定するにあたっては、同じ階層において存在する同じ属性の数が多くなるのに応じて大きくしていくように変更してよい。
【0091】
また、
図13(b)においては、ソースコード120における同じ階層において、条件文L4、L5の2つの条件文(IF文)が記述されている。このうち、条件文L4に含まれる「商品タイプ」の属性についての真の値は「国債」の1つのみである。
これに対して、条件文L5は、「IF ID = 10 OR 20 OR 30」と記述されているように、その条件式における「ID」の属性についての真の値は、「10」、「20」「30」の3である。つまり、条件文L5における真の値は複数である。このように、条件式に含まれる属性についての真の値が複数である場合、ネスト構造解析部103は、前記属性についての重み付け値を小さく変更するように設定する。
【0092】
一例として、ネスト構造解析部103は、条件文L4に含まれる「商品タイプ」の属性に対してはデフォルトとしての「0.4」の重み付け値を設定する。
これに対して、条件文L5に含まれる「ID」の属性については、デフォルトの「0.4」より低い重み付け値として、例えば、「0.4」の1/2倍の「0.2」を設定する。なお、このように重み付け値を小さくするように設定するにあたっては、真の値の数が多くなるのに応じて小さくするように変更してよい。
【0093】
また、ネスト構造解析部103は、条件式の内容によっては、条件式に含まれる属性についての偽の値が複数である場合、前記属性についての重み付け値を小さく変更するように設定してもよい。つまり、ネスト構造解析部103は、ソースコードの条件式に含まれる属性についての真偽を示す値が複数である場合、属性についての重み付け値を小さく変更するように設定するものである。
【0094】
なお、第2の実施形態におけるネスト構造解析部103が既存の商品ごとの属性間の順序関係を設定するにあたっては、
図13(a)のみの手法を採用してもよいし、
図13(b)のみの手法を採用してもよいし、
図13(a)と
図13(b)の手法を併用してもよい。
【0095】
そして、第2の実施形態における優先順設定部104は、既存の商品ごとの属性間の順序関係の設定根拠である重み付け値を利用して、ソースコード120において記述される属性ごとの優先順を設定する。具体的には、重み付け値の高い属性の順にしたがって優先順を設定すればよい。
【0096】
ただし、第2の実施形態においては、特に
図13(b)の手法が採用された場合に、ネスト情報テーブル300におけるネスト情報間で、同じ属性に設定された重み付け値が異なる可能性がある。
具体例として、
図14(a)においては、ネスト情報ID=「1」と「2」のネスト情報における「商品タイプ」の属性に対する重み付け値Kは「1.0」であるのに対して、ネスト情報ID=「3」の「商品タイプ」の属性に対する重み付け値Kは「1.2」である。
【0097】
また、ネスト情報ID=「1」と「2」のネスト情報における「償還期間」の属性に対する重み付け値Kは「0.8」であるのに対して、ネスト情報ID=「3」の「償還期間」の属性に対する重み付け値Kは「0.5」である。
【0098】
また、ネスト情報ID=「1」のネスト情報における「ID」の属性に対する重み付け値Kは「0.3」であるのに対して、ネスト情報ID=「3」の「ID」の属性に対する重み付け値Kは「0.4」である。
【0099】
このような場合には、例えば所定の規則にしたがって属性に対して1つの正規の重み付け値を決定する。例えば、優先順設定部104は、例えば複数の重み付け値のうちの最頻値、最大値、最小値のいずれかを正規の重み付け値として決定することができる。あるいは、優先順設定部104は、複数の重み付け値の平均値を算出し、この平均値を正規の重み付け値として決定することができる。
【0100】
図14(b)は、優先順設定部104が、
図14(a)のネスト情報テーブル300に対応して、平均値の算出により求めた正規の重み付け値にしたがって優先順を設定した場合の優先順情報400を示している。
この優先順情報400においては、「商品タイプ」、「償還期限」、「購入金額」、「販売所」、「ID」、「購入者」の順で優先順が設定されている。「商品タイプ」の重み付け値Kは「1.1」、「償還期間」の重み付け値Kは「0.7」、「購入金額」の重み付け値Kは「0.6」、「販売所」の重み付け値Kは「0.4」、「ID」の重み付け値Kは「0.35」、「購入者」の重み付け値Kは「0.3」である。
【0101】
そして、第2の実施形態における類似商品判定部105は、既存の商品についての新商品との類似度を以下のように求める。
図15(a)には、
図9(b)と同様の新商品属性テーブル600が示されている。また、
図15(b)には、優先順設定部104が設定した優先順にしたがって類似商品判定部105が生成した既存商品属性テーブル500の例が示されている。なお、この図に示す属性ごとの重み付け値Kは、説明の便宜上、
図14(b)とは異なる結果のものを用いている。この
図15(b)の例では、「商品タイプ」(重み付け値K=0.8)、「償還期間」(重み付け値K=0.6)、「購入者」(重み付け値K=0.4)、「ID」(重み付け値K=0.3)・・・の優先順となっている。
【0102】
そのうえで、第2の実施形態における類似商品判定部105は、既存商品属性テーブル500における行(既存の商品)ごとに、新商品属性テーブル600と内容が一致している属性を特定する。そして、内容が一致していた属性の重み付け値を加算することにより、既存商品属性テーブル500における行(既存の商品)ごとの類似度を求める。
図15の場合であれば、
図15(b)においてハッチングで示すように、既存商品属性テーブル500の1行目においては、「商品タイプ」の属性と「償還期間」の2つの属性の内容が、それぞれ、「国債」と「10年」で新商品属性テーブル600と一致している。この場合、「商品タイプ」の属性の重み付け値が0.8で、「償還期間」の属性の重み付け値が0.6なので、類似度は1.4である。
また、既存商品属性テーブル500の2行目においては、「商品タイプ」の属性と「購入者」の2つの属性の内容が、それぞれ、「国債」と「個人」で新商品属性テーブル600と一致している。したがって、この既存商品属性テーブル500の2行目に対応する類似度は1.2である。
また、既存商品属性テーブル500の3行目においては、「償還期間」の属性の内容のみが「10年」で新商品属性テーブル600と一致している。したがって、この既存商品属性テーブル500の3行目に対応する類似度は0.6である。
【0103】
このように類似度を求めたうえで、類似商品判定部105は、類似度が最大値のものを類似商品として判定する。つまり、
図15の場合には、既存商品属性テーブル500の1行目における「ID=10」の商品が類似商品であるとして判定される。
【0104】
[処理手順例]
図16のフローチャートは、第2の実施形態におけるネスト構造解析部103が、
図11のステップS103として実行するネスト情報生成のための処理手順例を示している。
【0105】
ネスト構造解析部103は、まず、抽象構文木200におけるルートのノードを選択する(ステップS301)。
【0106】
そのうえで、ネスト構造解析部103は、選択しているノードがIF文(条件文)であるか否かについて判定する(ステップS302)。
IF文である場合(ステップS302−YES)、ネスト構造解析部103は、そのIF文の条件式の内容にしたがって、
図13にて説明したように、そのIF文に含まれる属性についての重み付け値を設定する(ステップS303)。そして、ネスト構造解析部103は、その条件式に含まれていた属性に、ステップS303により設定した重み付け値を対応付けて保持し(ステップS304)、この後にステップS305に進む。
【0107】
IF文でない場合(ステップS302−NO)、また、ステップS304を実行した後、ネスト構造解析部103は、現在選択しているノードの子ノードのうちで、未探索の子ノードが存在するか否かについて判定する(ステップS305)。
【0108】
未探索の子ノードが存在しない場合(ステップS305−NO)、つまり、最も深い階層のノードに到達した場合、ネスト構造解析部103は、現在において保持しているすべての属性とこれらに対応付けられている重み付け値を1つのネスト情報として出力する(ステップS306)。このように、最も深い階層のノードにまで探索されるごとにネスト情報が1つずつ順次出力され、これらのネスト情報によりネスト情報テーブル300が生成される。
【0109】
次に、ネスト構造解析部103は、ステップS306により出力した属性とこれらに対応付けられた重み付け値のデータを消去する(ステップS307)。
【0110】
次に、ネスト構造解析部103は、これまでに選択しているノードの親ノードに選択を変更したうえで(ステップS308)、この選択した親ノードを子とする子ノードのうちで未探索のものが存在するか否かについて判定する(ステップS309)。
【0111】
未探索の子ノードが存在する場合(ステップS309−YES)、ネスト構造解析部103は、未探索の子ノードを1つ選択し(ステップS310)、ステップS302の処理に戻る。これにより、他のブロック(つまり、他の既存の商品)に対応するネスト情報を生成するための処理に移行する。
【0112】
一方、未探索の子ノードが存在しない場合(ステップS309−NO)、ネスト構造解析部103は、さらに、ステップS307により選択した親ノードが抽象構文木200のルートか否かについて判定する(ステップS311)。
【0113】
抽象構文木200のルートでない場合(ステップS311−NO)、ネスト構造解析部103は、ステップS308に戻ることで、前回のステップS308により選択した親ノードの親ノードをさらに選択する。
そして、抽象構文木200のルートである場合には(ステップS311−YES)、抽象構文木200におけるすべてのノードが探索され、すべてのブロック(既存の商品)に対応するネスト情報が得られている。この場合、ネスト構造解析部103は、これまでの抽象構文木200の探索を終了する。
【0114】
なお、これまでの説明では、IF文に含まれる属性を対象として重み付けを行っているが、例えば、IF−ELSE文などの他の条件文に含まれる属性を対象とすることも考えられる。
また、第1の実施形態におけるネスト構造解析部103も、
図16に準じた探索処理を行うことにより、
図8(a)に示したネスト情報テーブル300を生成することができる。ただし、第1の実施形態においては、ステップS303による重み付け値の設定は行う必要はなく、ステップS304においては、条件式に含まれていた属性のみを保持すればよい。また、ステップS306においては、保持している属性のみによるネスト情報を出力すればよく、ステップS307においては、出力済みの属性のみを消去すればよい。
【0115】
図17のフローチャートは、第2の実施形態における類似商品判定部105が
図11のステップS105として実行する類似商品判定のための処理手順例を示している。
【0116】
まず、類似商品判定部105は、例えば
図9(b)に示した新商品属性テーブル600を予め生成する(ステップS401)。
【0117】
次に、類似商品判定部105は、
図9(a)、(c)に示した既存商品属性テーブル500における行番号を示す変数nに「1」を代入する(ステップS402)。
【0118】
次に、類似商品判定部105は、既存商品属性テーブル500におけるn行目を選択する(ステップS403)。
そして、類似商品判定部105は、n行目の既存の商品と新商品とで属性ごとに内容を比較する(ステップS404)。そして、類似商品判定部105は、ステップS404による比較結果に基づいて、n行目の既存の商品についての新商品との類似度Dを算出する(ステップS405)。この類似度Dは、
図15にて説明したように、内容が一致した属性の重み付け値を加算することにより求めることができる。
【0119】
次に、類似商品判定部105は、変数nが最大値であるか否かについて判定する(ステップS406)。
変数nが最大値ではない場合(ステップS406−NO)、類似商品判定部105は、変数nをインクリメントしたうえで(ステップS407)、ステップS403に戻ることで、既存商品属性テーブル500における次の行を対象として属性内容の比較を行う。
一方、変数nが最大値である場合(ステップS406−YES)、類似商品判定部105は、類似度Dが最大値の行に対応する既存の商品を類似商品として判定する(ステップS408)。
【0120】
[変形例]
なお、本実施形態の変形例として、優先順設定については、第1の実施形態と、第2の実施形態とが以下のように組み合わされてもよい。
つまり、変形例におけるネスト構造解析部103は、第2の実施形態にしたがって重み付け値を対応付けて属性の順序関係を設定する。
そのうえで、優先順設定部104は、まず、推移律により属性ごとの優先順を設定する。そして、推移律に基づいて優先順を設定した結果、優先順が同じとなった複数の属性については、さらに、これら複数の属性に設定された重み付け値を利用して異なる優先順を設定するというものである。つまり、推移律に基づいて設定した優先順が同じとなった複数の属性については、改めて、これら複数の属性に設定された重み付け値により異なる優先順を決定するものである。
この際において、
図14にて説明したように、ネスト情報間において同じ属性に対して設定された重み付け値が複数存在する状態となった場合には、平均値を求めるなどの所定の演算によって1つの正規の重み付け値を決定すればよい。
【0121】
また、これまでの実施形態の説明にあっては金融商品を例に挙げているが、例えば保険商品や証券などであってもよい。また、これら以外にも、例えばクレジットカードの審査などをあはじめ、申込みの際に審査が必要となる多様なサービスなどにも対応できる。
【0122】
また、
図1に示す各機能部の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによりソースコードの処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、OSや周辺機器等のハードウェアを含むものとする。
【0123】
また、「コンピュータシステム」は、WWWシステムを利用している場合であれば、ホームページ提供環境(あるいは表示環境)も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、CD−ROM等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ(RAM)のように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。
【0124】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。