JP5207007B2 - モデル検証システム、モデル検証方法および記録媒体 - Google Patents
モデル検証システム、モデル検証方法および記録媒体 Download PDFInfo
- Publication number
- JP5207007B2 JP5207007B2 JP2011513396A JP2011513396A JP5207007B2 JP 5207007 B2 JP5207007 B2 JP 5207007B2 JP 2011513396 A JP2011513396 A JP 2011513396A JP 2011513396 A JP2011513396 A JP 2011513396A JP 5207007 B2 JP5207007 B2 JP 5207007B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- unit
- formal language
- design
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3604—Software analysis for verifying properties of programs
- G06F11/3608—Software analysis for verifying properties of programs using formal methods, e.g. model checking, abstract interpretation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/72—Code refactoring
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/20—Software design
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Stored Programmes (AREA)
Description
本発明は、モデルとして蓄積されたプログラムの設計を検証するモデル検証システム、モデル検証方法およびモデル検証システム用プログラムに関する。特に、人間の目視に対応する形態に作成されたモデル図データを用いて、プログラムの設計を検証するモデル検証システム、モデル検証方法およびモデル検証プログラムに関する。
近年、モデルドリブンアーキテクチャという名称で、モデルからプログラムを自動生成する開発手法が存在する。この開発手法によって、システム開発者（プログラマー）は、プログラミング言語の文字による記述方法を覚えなくても、一連の処理フローを予め決められた図形表現を組み合わせることで、プログラミングできる。
上記モデルドリブンアーキテクチャで用いられる図形表現は、視覚的にわかりやすい様に割当てられた処理を表現し、予め又は付加的に当該処理に対応するプログラムが関連付けられる。図形表現に対応付けられたプログラムは、図形表現上で他の図形と組み合わせられることで、他の図形のプログラムと連結されてもちいられる。
このような図形表現に対応付けられたプログラムや、一連の処理としてまとめられたプログラムでは、同じ結果を得られる処理を行うプログラムであっても、開発者の熟練度等によって簡潔に記述できている設計のプログラムと、そうでない設計のプログラムとがある。このため、複数人の開発者が関わったプログラムでは、良い設計と悪い設計が混在することが往々として発生する。尚、ここで言う悪い設計のプログラムとは、良い設計と同様の結果を得られるものの、処理に要する時間が良い設計のプログラムより長いものや、リソースを多大に消費するプログラムを指す。また、図形表現に対応付けられたプログラムは、所定のシステムに対しては良い設計であっても、他のシステムにおいて悪い設計となることもある。
ところで、製品開発では、過去に設計済みであるプログラムを使用することが多い。過去に設計済みであるプログラムが複数あって何れも正常に動作する場合、良い設計のプログラムと悪い設計のプログラムとを区別しきれずに何れかを使用することとなる。他方、製品開発時に悪い設計のプログラムを多く含むこととなると、製品としての性能が低下する。
そこで、悪い設計を良い設計に改善する活動（リファクタリング）が重要になる。しかし、プログラムソースを人手で確認してリファクタリングすることは、非常に困難である。これは、改善活動自体も熟練度に依存すること、また改善候補が過去のシステム全てとなり、数が多くなってしまうことなどに起因する。また、熟練者にもリファクタリングに癖や偏りがあり、リソースの削減や処理時間の短縮など多くの項目に対して、正当に評価することは難しい。
そのため、システム開発時点やシステムの改変時点において、オプティマイズなどの最適化を考慮したシステムが求められている。
関連するシステムとしては、例えば特許文献１（特開２００３−３３７６９７号公報）及び特許文献２（特開２００５−１７４１２０号公報）が挙げられる。
特許文献１に記載されているビジネスシステムの開発システムは、オリジナルモデル記憶手段と、リファクタリングルール記憶手段と、オプティマイズドモデル記憶手段とから構成されている。上記ビジネスシステムの開発システムは、つぎのように動作する。ＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）による統一的な表現方法を用いてオリジナルモデルを記述し、最適化するための熟練者（コンサルタント）によって定められた主観的なリファクタリングルールを適用することで、オプティマイズドモデルを生成する。
また、特許文献２には、言語（文字）で表現されたプログラムデータ（ソース）の構造的類似性を解析する技術の一例が記載されている。特許文献２に記載されたＷｅｂサービス接続処理システムは、想定接続先のＷＥＢサービスと、新規接続先のＷｅｂサービスとの定義文書を比較する。そして、類似性判定処理として、２つのＷｅｂサービス定義文書の引数と戻り値のデータ型情報を読み込み、その差異を抽出し、抽出結果に基づいて構造的類似性を算出する。システムは、類似している場合、変換ルールを生成し、ルールに従ってＷｅｂサービスを適切に呼び出す。
上記モデルドリブンアーキテクチャで用いられる図形表現は、視覚的にわかりやすい様に割当てられた処理を表現し、予め又は付加的に当該処理に対応するプログラムが関連付けられる。図形表現に対応付けられたプログラムは、図形表現上で他の図形と組み合わせられることで、他の図形のプログラムと連結されてもちいられる。
このような図形表現に対応付けられたプログラムや、一連の処理としてまとめられたプログラムでは、同じ結果を得られる処理を行うプログラムであっても、開発者の熟練度等によって簡潔に記述できている設計のプログラムと、そうでない設計のプログラムとがある。このため、複数人の開発者が関わったプログラムでは、良い設計と悪い設計が混在することが往々として発生する。尚、ここで言う悪い設計のプログラムとは、良い設計と同様の結果を得られるものの、処理に要する時間が良い設計のプログラムより長いものや、リソースを多大に消費するプログラムを指す。また、図形表現に対応付けられたプログラムは、所定のシステムに対しては良い設計であっても、他のシステムにおいて悪い設計となることもある。
ところで、製品開発では、過去に設計済みであるプログラムを使用することが多い。過去に設計済みであるプログラムが複数あって何れも正常に動作する場合、良い設計のプログラムと悪い設計のプログラムとを区別しきれずに何れかを使用することとなる。他方、製品開発時に悪い設計のプログラムを多く含むこととなると、製品としての性能が低下する。
そこで、悪い設計を良い設計に改善する活動（リファクタリング）が重要になる。しかし、プログラムソースを人手で確認してリファクタリングすることは、非常に困難である。これは、改善活動自体も熟練度に依存すること、また改善候補が過去のシステム全てとなり、数が多くなってしまうことなどに起因する。また、熟練者にもリファクタリングに癖や偏りがあり、リソースの削減や処理時間の短縮など多くの項目に対して、正当に評価することは難しい。
そのため、システム開発時点やシステムの改変時点において、オプティマイズなどの最適化を考慮したシステムが求められている。
関連するシステムとしては、例えば特許文献１（特開２００３−３３７６９７号公報）及び特許文献２（特開２００５−１７４１２０号公報）が挙げられる。
特許文献１に記載されているビジネスシステムの開発システムは、オリジナルモデル記憶手段と、リファクタリングルール記憶手段と、オプティマイズドモデル記憶手段とから構成されている。上記ビジネスシステムの開発システムは、つぎのように動作する。ＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）による統一的な表現方法を用いてオリジナルモデルを記述し、最適化するための熟練者（コンサルタント）によって定められた主観的なリファクタリングルールを適用することで、オプティマイズドモデルを生成する。
また、特許文献２には、言語（文字）で表現されたプログラムデータ（ソース）の構造的類似性を解析する技術の一例が記載されている。特許文献２に記載されたＷｅｂサービス接続処理システムは、想定接続先のＷＥＢサービスと、新規接続先のＷｅｂサービスとの定義文書を比較する。そして、類似性判定処理として、２つのＷｅｂサービス定義文書の引数と戻り値のデータ型情報を読み込み、その差異を抽出し、抽出結果に基づいて構造的類似性を算出する。システムは、類似している場合、変換ルールを生成し、ルールに従ってＷｅｂサービスを適切に呼び出す。
しかしながら、特許文献１に記載されたシステムの課題は、リファクタリングルールに属人性があり、オプティマイズドモデルがコンサルタントごとに異なる結果になる。即ち、リファクタリングルールを定めるコンサルタントの主観によって、オプティマイズドモデルの良し悪しが定まってしまう。また、このシステムは、真に、プログラムとしてリファクタリングを行なっていない。これは、特許文献１に記載されているリファクタリングルール（［００４３］参照）が、自然言語で記載されている点からも明らかである。また、プログラムの変更による効果を定量的に判断できない。
また、特許文献２に記載されたシステムは、生成した変換ルール自体および変換ルールを適用したプログラムの最適化については、何ら考慮されていない。
上記のようにプログラムの修正やリファクタリングルールの作成は、熟練者の能力に頼っている部分が多く、先に述べたようにリソースの削減や処理時間の短縮などの多くの項目に対して、修正されたプログラムが正当に評価されていない。即ち、非熟練者の作成したプログラムを自動的に評価する仕組みと共に、熟練者のサポートとなるシステム設計に関する検証手段を提供することが望まれる。
本発明は、上記課題に鑑みて成されたものであり、図形式（オブジェクトモデル）で表現された設計データを形式言語表現に変換し、変換した形式言語表現のデータを用いてバリエーションを自動的に増やすことで、変換元のオリジナル設計と、オリジナルの設計と異なる派生設計を自動的に収集してモデル検証を行なえるモデル検証システムの提供を目的とする。
また、特許文献２に記載されたシステムは、生成した変換ルール自体および変換ルールを適用したプログラムの最適化については、何ら考慮されていない。
上記のようにプログラムの修正やリファクタリングルールの作成は、熟練者の能力に頼っている部分が多く、先に述べたようにリソースの削減や処理時間の短縮などの多くの項目に対して、修正されたプログラムが正当に評価されていない。即ち、非熟練者の作成したプログラムを自動的に評価する仕組みと共に、熟練者のサポートとなるシステム設計に関する検証手段を提供することが望まれる。
本発明は、上記課題に鑑みて成されたものであり、図形式（オブジェクトモデル）で表現された設計データを形式言語表現に変換し、変換した形式言語表現のデータを用いてバリエーションを自動的に増やすことで、変換元のオリジナル設計と、オリジナルの設計と異なる派生設計を自動的に収集してモデル検証を行なえるモデル検証システムの提供を目的とする。
本発明のモデル検証システムは、プログラムが対応付けられて設計パターンとして登録されているモデル図データを、所定の形式言語の表現形式に基づく形式言語表現データに変換する形式言語変換部と、前記形式言語変換部によって変換した前記形式言語表現データに対して、前記形式言語での構成要素及び／又は属性情報に、修正を加えて仮想的に派生設計の形式言語表現データを生成する形式言語増殖部とを有することを特徴とする。
本発明によれば、図形式で表現された設計データを形式言語（例えばＸＭＬ Ｓｃｈｅｍａ）等に変換し、形式言語でのバリエーションを自動的に増やすことで、形式言語の変換元であるオリジナル設計と、オリジナルの設計と異なる派生設計を自動的に収集してモデル検証を行なえるモデル検証システムを提供できる。
図１は、第１の実施の形態のモデル検証システムの構成の一部を示す機能ブロック図である。
図２は、第１の実施の形態のモデル検証システムの構成を示す機能ブロック図である。
図３は、形式言語変換部１００の構成を示すブロック図である。
図４は、形式言語増殖部２００の構成を示すブロック図である。
図５は、設計抽出部３００の構成を示すブロック図である。
図６は、定量化部４００の構成を示すブロック図である。
図７は、選別部５００の構成を示すブロック図である。
図８は、等価性検証部６００の構成を示すブロック図である。
図９は、形式言語変換部１００の動作を示すフローチャートである。
図１０は、形式言語増殖部２００の動作を示すフローチャートである。
図１１は、設計抽出部３００の動作を示すフローチャートである。
図１２は、定量化部４００の動作を示すフローチャートである。
図１３は、選別部５００の動作を示すフローチャートである。
図１４は、等価性検証部６００の動作を示すフローチャートである。
図１５は、実施の形態におけるパターン蓄積部に格納されるＰａｔｔｅｒｎテーブルの構成例を示す図である。
図１６は、実施の形態におけるパターン蓄積部に格納されるＤｅｒｉｖａｂｌｅテーブルの構成例を示す図である。
図１７は、実施の形態におけるパターン蓄積部に格納されるＰｒｏｐｏｓａｌテーブルの構成例を示す図である。
図１８は、実施の形態における既存システム設計蓄積部に格納されるＩｎｓｔａｎｃｅテーブルの構成例を示す図である。
図１９は、実施の形態における既存システム実行ログ蓄積部に格納されるＬＯＧテーブルの構成例を示す図である。
図２０は、実施の形態におけるＫＰＩ（Ｋｅｙ Ｐｅｒｆｏｒｍａｎｃｅ Ｉｎｄｉｃａｔｏｒ）算出方式格納部に格納されるＫＰＩテーブルの構成例を示す図である。
図２１は、実施の形態におけるＫＰＩ算出方式格納部に格納されるＫＰＩ＿ＶＡＬＵＥ＿ＦＲＯＭテーブルの構成例を示す図である。
図２２は、実施の形態におけるＫＰＩ算出方式格納部に格納されるＱｕａｎｔｉｔｙテーブルの構成例を示す図である。
図２３は、実施の形態における既存システムテストデータ蓄積部に格納されるＴＥＳＴテーブルの構成例を示す図である。
図２４は、実施の形態における形式言語変換部及び設計抽出部で参照される対応表の構成例を示す図である。
図２５は、実施例１のスキーマの増殖、定量化を模式的に記した説明図である。
図２６は、実施例１によって得られる改善価値を記した説明図である。
図２７は、第２の実施の形態における形式言語変換部１００の構成を示すブロック図である。
図２８は、第２の実施の形態における設計抽出部３００の構成を示すブロック図である。
図２９は、実施例２の入力設計図を記したシーケンス図である。
図３０は、実施例２の入力設計図をＸＭＬスキーマに変換した結果を示す説明図である。
図３１は、実施例３のスキーマの増殖、定量化を模式的に記した説明図である。
図３２は、実施例３における設計抽出部３００の動作を示すフローチャートである。
図３３は、実施例３における形式言語変換部及び設計抽出部で参照される対応表の構成例を示す図である。
図３４は、コンピュータに構築されたモデル検証システムを例示する構成図である。
図２は、第１の実施の形態のモデル検証システムの構成を示す機能ブロック図である。
図３は、形式言語変換部１００の構成を示すブロック図である。
図４は、形式言語増殖部２００の構成を示すブロック図である。
図５は、設計抽出部３００の構成を示すブロック図である。
図６は、定量化部４００の構成を示すブロック図である。
図７は、選別部５００の構成を示すブロック図である。
図８は、等価性検証部６００の構成を示すブロック図である。
図９は、形式言語変換部１００の動作を示すフローチャートである。
図１０は、形式言語増殖部２００の動作を示すフローチャートである。
図１１は、設計抽出部３００の動作を示すフローチャートである。
図１２は、定量化部４００の動作を示すフローチャートである。
図１３は、選別部５００の動作を示すフローチャートである。
図１４は、等価性検証部６００の動作を示すフローチャートである。
図１５は、実施の形態におけるパターン蓄積部に格納されるＰａｔｔｅｒｎテーブルの構成例を示す図である。
図１６は、実施の形態におけるパターン蓄積部に格納されるＤｅｒｉｖａｂｌｅテーブルの構成例を示す図である。
図１７は、実施の形態におけるパターン蓄積部に格納されるＰｒｏｐｏｓａｌテーブルの構成例を示す図である。
図１８は、実施の形態における既存システム設計蓄積部に格納されるＩｎｓｔａｎｃｅテーブルの構成例を示す図である。
図１９は、実施の形態における既存システム実行ログ蓄積部に格納されるＬＯＧテーブルの構成例を示す図である。
図２０は、実施の形態におけるＫＰＩ（Ｋｅｙ Ｐｅｒｆｏｒｍａｎｃｅ Ｉｎｄｉｃａｔｏｒ）算出方式格納部に格納されるＫＰＩテーブルの構成例を示す図である。
図２１は、実施の形態におけるＫＰＩ算出方式格納部に格納されるＫＰＩ＿ＶＡＬＵＥ＿ＦＲＯＭテーブルの構成例を示す図である。
図２２は、実施の形態におけるＫＰＩ算出方式格納部に格納されるＱｕａｎｔｉｔｙテーブルの構成例を示す図である。
図２３は、実施の形態における既存システムテストデータ蓄積部に格納されるＴＥＳＴテーブルの構成例を示す図である。
図２４は、実施の形態における形式言語変換部及び設計抽出部で参照される対応表の構成例を示す図である。
図２５は、実施例１のスキーマの増殖、定量化を模式的に記した説明図である。
図２６は、実施例１によって得られる改善価値を記した説明図である。
図２７は、第２の実施の形態における形式言語変換部１００の構成を示すブロック図である。
図２８は、第２の実施の形態における設計抽出部３００の構成を示すブロック図である。
図２９は、実施例２の入力設計図を記したシーケンス図である。
図３０は、実施例２の入力設計図をＸＭＬスキーマに変換した結果を示す説明図である。
図３１は、実施例３のスキーマの増殖、定量化を模式的に記した説明図である。
図３２は、実施例３における設計抽出部３００の動作を示すフローチャートである。
図３３は、実施例３における形式言語変換部及び設計抽出部で参照される対応表の構成例を示す図である。
図３４は、コンピュータに構築されたモデル検証システムを例示する構成図である。
次に、本発明の実施の形態について、図面を参照して詳細に説明する。
図１は、第１の実施の形態のモデル検証システムの構成の一部を示す機能ブロック図である。図２は、第１の実施の形態のモデル検証システムの構成を示す機能ブロック図である。
図１及び図２を参照すると、本発明の第１の実施の形態は、プログラム制御により動作する形式言語変換部１００と、形式言語増殖部２００と、設計抽出部３００と、定量化部４００と、選別部５００と、等価性検証部６００と、パターン蓄積部１０００と、既存システム設計蓄積部１１００と、既存システム実行ログ蓄積部１２００と、ＫＰＩ算出方式格納部１３００と、既存システムテストデータ蓄積部１４００と、対応表蓄積部１５００とから構成されている。
パターン蓄積部１０００には、設計の参考に用いる典型的なモデル図（オブジェクトモデルデータ）が登録（記憶）されている。また、典型的なモデル図から生成された派生設計が登録される。さらに、複数の設計を別の設計に置き換えた場合に得られる効果を示した改善提案が登録される。また、パターン蓄積部１０００には、典型的なモデル図の評価指標となるＫＰＩ値リファレンスが記録される。
既存システム設計蓄積部１１００には、複数の設計情報が格納される。これらの設計情報は、実際に動作しているシステム（既存システム）の設計情報であり、改善の余地がある設計や優れた設計など、様々な完成度を持った設計情報である。
既存システム実行ログ蓄積部１２００には、複数の設計によって動作しているシステムのログが何処に格納されているか、またログの中から重要な情報を抽出するための正規表現が格納されている。
ＫＰＩ算出方式格納部１３００には、ＫＰＩの推奨範囲と、ＫＰＩ値を算出する関数と、関数の入力となるログデータの参照先が格納されている。さらに実際のログを用いて算出したＫＰＩ値を格納する。
既存システムテストデータ蓄積部１４００には、複数の設計の動作確認に利用したテストデータが格納されている。また、既存システムテストデータ蓄積部１４００には、テストケースを実行するために必要な入力データ、実行後に期待される結果を示す検証データが記録される。
対応表蓄積部１５００には、形式言語変換部１００等で参照される形式言語の変換や設計抽出に用いられる対応表が蓄積される。
図３は、形式言語変換部１００の構成を示すブロック図である。形式言語変換部１００は、データ型判定部１１０と、データパラメータ抽出部１２０と、形式言語表現生成部１３０とを含む。
各部はそれぞれ概略つぎのように動作する。
データ型判定部１１０は、パターン蓄積部１０００から設計パターンとして登録されているモデル図が記載されたファイルを読み出し、当該ファイルを拡張子もしくはファイル先頭部に定義された型情報などを識別してその情報に基づいて、適切なデータパラメータ抽出部１２０に転送する。
データパラメータ抽出部１２０は、ファイルの内容からモデル図を特徴づけるパラメータを抽出して形式言語生成部１３０に転送する。パラメータの一例としては、モデルに含まれる要素間の関係や多重度などを挙げることができる。
形式言語生成部１３０は、抽出されたパラメータから、形式言語表現（データ）を生成する。形式言語表現の一例として、ＸＭＬスキーマや、ＸＰａｔｈ、Ｒｅｇｕｌａｒ Ｌａｎｇｕａｇｅ ｄｅｓｃｒｉｐｔｉｏｎ ｆｏｒ ＸＭＬ等が存在する。生成された形式言語で表現されたデータは、形式言語増殖部２００に送られる。
形式言語変換部１００は、データ型判定部１１０によって判定される型の数だけ、データパラメータ抽出部１２０と形式言語表現生成部１３０の組を追加可能な構造であり、将来新しく定義されたモデル図（拡張子や型情報を含む）も対応可能である。
図４は、形式言語増殖部２００の構成を示すブロック図である。形式言語増殖部２００は、要素増殖部２１０と、要素置換部２２０と、要素削減部２３０と、統合部２４０とを含む。
各部はそれぞれ概略つぎのように動作する。
要素増殖部２１０は、形式言語で表現されたデータに、「任意の要素」を示すデータを挿入する。挿入する任意の要素数の上限は、システム利用者が変更できるようになっている。
要素置換部２２０は、形式言語で表現されたデータの一部を、「任意の要素」を示すデータに置き換える。置き換える要素数の上限は、形式言語で表現されたデータサイズに応じて決定される。
要素削減部２３０は、形式言語で表現されたデータの一部を削除する。削除する要素数の上限は、形式言語で表現されたデータサイズに応じて決定される。
統合部２４０は、要素増殖部２１０、要素置換部２２０、要素削減部２３０の結果を組み合わせてデータを生成する。結果の組み合わせは、形式言語で表現されたデータサイズに基づいて行なっても良いし、システム利用者の任意の指示に基づいても良い。
形式言語増殖部２００は、要素増殖部２１０と、要素置換部２２０と、要素削減部２３０と、統合部２４０から生成した全てのデータ（派生形式言語表現データ）と形式言語変換部１００で生成されたオリジナルデータ（形式言語表現データ）を、設計抽出部３００に転送する。
尚、形式言語増殖部２００は、要素増殖部２１０と、要素置換部２２０と、要素削減部２３０と、統合部２４０を全て有せずとも、何れかのみを備える形態でも動作させてもよい。
図５は、設計抽出部３００の構成を示すブロック図である。設計抽出部３００は、データ型判定部３１０と、データパラメータ抽出部３２０と、情報表現生成部３３０と、合致判定部３４０とを含む。
各部はそれぞれ概略次のように動作する。
データ型判定部３１０は、既存システム設計部１１００から１つ設計情報のファイルを取り出し、当該ファイルを拡張子もしくは先頭部に定義された型情報を識別してその情報に基づき、適切なデータパラメータ抽出部３２０に転送する。
データパラメータ抽出部３２０は、ファイルの内容からモデル図を特徴づけるパラメータを抽出する。
情報表現生成部３３０は、抽出されたパラメータに基づき、モデル図を別の情報記述表現でデータを表現する。この情報記述表現は、対応表蓄積部１５００に記録されている対応表を用いて、形式言語表現生成部１３０で生成された形式言語表現によって、検証や要素の抽出などが可能になるように定義された形式に限定する。例えば、形式言語表現がＸＭＬスキーマやＸＰａｔｈであれば、情報記述表現はＸＭＬとする。尚、ＸＭＬスキーマ形式のデータは、ＸＭＬ言語や後述するＢＰＥＬ言語に対して、文法の検査や、文法の一部を抽出して検査することに用いることが可能である。また、ＸＰａｔｈ形式のデータは、ＸＭＬ言語や後述するＢＰＥＬ言語で記載された情報に対して、文章の一部を抽出することに用いることが可能である。
合致判定部３４０は、形式言語で表現されたデータと、情報記述表現で表現されたデータが合致するか否か判定し、その結果（判定結果データ）を定量化部４００に通知するともに、既存システム設計蓄積部１１００に記録する。
図６は、定量化部４００の構成を示すブロック図である。定量化部４００は、合致ペア管理部４１０と、ログ管理部４２０と、ＫＰＩ算出部４３０とを含む。
各部はそれぞれ概略次のように動作する。
合致ペア管理部４１０は、設計抽出部３００で合致すると判定されたデータ（判定結果データ）のパターンＩＤとインスタンスＩＤを記憶する。
ログ管理部４２０は、既存システム実行ログ蓄積部１２００から、インスタンスＩＤにマッチするログを取得する。
ＫＰＩ算出部４３０は、パターンＩＤからパターン蓄積部１０００に記憶されるＫＰＩ値リファレンスをたどり、ＫＰＩ算出方式格納部１３００に格納されたＫＰＩ推奨範囲値を抽出する。また、ＫＰＩ算出部４３０は、同様にＫＰＩ値リファレンスをたどり、ＫＰＩ算出方式格納部１３００に格納されたＫＰＩ算出関数を取得する。また、ＫＰＩ算出部４３０は、マッチしたログをＫＰＩ算出関数に適用して値を算出し、その結果データを選別部５００に転送する。
図７は、選別部５００の構成を示すブロック図である。選別部５００は、置き換え対象管理部５１０と、ＲＯＩ（Ｒｅｔｕｒｎ ｏｎ Ｉｎｖｅｓｔｍｅｎｔ）計算部５２０とを含む。
各部はそれぞれ概略次のように動作する。
置き換え対象管理部５１０は、既存システム設計蓄積部１１００に記録された設計情報の定量化結果（形式評価結果）を参照し、同じパターンを参照しているインスタンス同士を１つのグループとして、定量化部４００から得たＫＰＩ値の大小を比較する。同一グループ内で、最もスコアの高いインスタンスを置き換え先候補（置換候補）として、パターン蓄積部１０００に記録する。また、最高スコア以外のインスタンスを置き換え元候補（被置換候補）として置換候補と関連付けて記録し、候補間関係を記録する。
ＲＯＩ計算部５２０は、置き換え先候補のＫＰＩ値を置き換え元候補のＫＰＩ値で割って比率を求め、置き換えを行なった場合の定量的な効果を算出し、ＲＯＩ値としてパターン蓄積部１０００に記録する。
図８は、等価性検証部６００の構成を示すブロック図である。等価性検証部６００は、テストデータ抽出部６１０と、テスト実行部６２０とを含む。
各部はそれぞれ概略次のように動作する。
テストデータ抽出部６１０は、置き換え元候補のインスタンスのうち、パターンにマッチする部分のみを利用するテストケースを、既存システムテストデータ蓄積部１４００から抽出すると共に、テストケースを実行するために必要な入力データと、実行後に期待される結果を示す検証データを取得する。
テスト実行部６２０は、置き換え元候補それぞれについて入手した入力データと検証データを、置き換え先候補のテストケースに適用してテストを実行し、置換可能であるか否かの結果をパターン蓄積部１０００に記録する。
このように動作させて、最終的に、テスト結果を用いて、改善元のスコアと改善先のスコア比率によって、改善効果を定量的に示す。
次に、図３から図８まで、図９から図１４のフローチャートを参照して本実施の形態のモデル検証システム全体の動作について詳細に説明する。
以下では、扱うモデル図をサービスを呼び出すシーケンス図とし、形式言語表現をＸＭＬスキーマとし、情報記述表現をＸＭＬとする。また、各種記憶手段には、Ｐａｔｔｅｒｎテーブル、Ｄｅｒｉｖａｂｌｅテーブル、Ｐｒｏｐｏｓａｌテーブル、ＫＰＩ＿ＶＡＬＵＥ＿ＦＲＯＭテーブル、Ｑｕａｎｔｉｔｙテーブル、ＫＰＩテーブルテーブル、Ｉｎｓｔａｎｃｅテーブル、ＬＯＧテーブル、及びＴＥＳＴテーブルが格納されており、各種動作に用いられる。
ここで、各テーブルについて説明する。
Ｐａｔｔｅｒｎテーブル（設計パターンテーブル）は、典型的なモデル図の設計データが格納された場所（アドレス）と、その設計の評価指標（ＫＰＩ値）と、形式言語変換部１００でモデル図から生成した形式言語表現の文字列をＩＤで対応付けて格納する。ＫＰＩ値は外部キーであり、ＫＰＩテーブルを参照している。
Ｄｅｒｉｖａｂｌｅテーブル（抽出テーブル）は、形式言語増殖部２００によって増殖された典型的なモデル図の形式言語表現が格納される。また、形式言語表現の元となった派生元パターンもあわせて格納されている。派生元パターンの値は外部キーであり、Ｐａｔｔｅｒｎテーブルを参照している。
Ｐｒｏｐｏｓａｌテーブル（提案テーブル）は、改善すべき設計候補と、改善内容の設計候補を格納する。特に、Ｆｒｏｍ欄に改善すべき候補をＩｎｓｔａｎｃｅテーブルへの外部キーとして記載し、Ｔｏ欄に改善内容の候補をＩｎｓｔａｎｃｅテーブルへの外部キーとして記載する。また、Ｆｒｏｍ欄の設計をＴｏ欄の設計に置き換えた場合に、改善効果を定量的に表現するＲＯＩ欄と、置き換えテストの合否を記録するＰＡＳＳ欄を持つ。
ＫＰＩテーブル（重要業績指標テーブル）は、ＫＰＩを算出する関数と、ＫＰＩの値域、目標値、最低ラインを記載する。
ＫＰＩ＿ＶＡＬＵＥ＿ＦＲＯＭテーブル（重要業績指標関連付テーブル）は、ＫＰＩを算出する関数と、関数の入力となるログデータの関連付けを行う。関数欄にＫＰＩを算出する関数をＫＰＩテーブルへの外部キーとして記載する。また、入力データ欄に関数への入力データとなるＬＯＧテーブルへの外部キーとして記載する。
Ｑｕａｎｔｉｔｙテーブル（定量評価テーブル）は、設計情報をある指標で評価した場合のスコアを記載する。比較に利用したＫＰＩ欄に、ＫＰＩテーブルへの外部キーを記載する。また、インスタンス欄に、インスタンステーブルへの外部キーを記載する。
Ｉｎｓｔａｎｃｅテーブル（実証テーブル）は、設計情報の格納場所と、設計情報を情報言語で表現した文字列と、類似するパターン（設計情報）への参照データが格納される。この参照データは、Ｐａｔｔｅｒｎテーブルへの外部キーである。
ＬＯＧテーブルは、設計情報を元に作成したシステムの動作ログの格納場所と、そのログから抽出すべきデータが正規表現で記載されている。設計情報を示すインスタンスＩＤ欄は、インスタンステーブルへの外部キーとなっている。
ＴＥＳＴテーブルは、設計情報と関連付けて、システムの動作を保障するテストで利用されるプロセスデータ、入力データ、検証データが格納される。設計情報を示すインスタンスＩＤ欄は、インスタンステーブルへの外部キーとなっている。
まず、形式言語変換部１００がモデル図を形式言語に変換する動作を、図３と図９を用いて説明する。
図９は、形式言語変換部１００の動作を示すフローチャートである。
データ型判定部１１０は、入力を受け付けたモデル図が記載されたファイルの拡張子″．ｕｍｌ″を対応表蓄積部１５００に格納されている対応表（図２４もしくは図３３参照）に照らし合わせ、読み込み対応可能か否か判定し、対応可能であるデータをデータパラメータ抽出部１２０に転送する（ステップＳ１０１）。
データパラメータ抽出部１２０は、モデル図であるシーケンス図からサービスコンポーネント、呼び出し順序のパラメータを抽出する（ステップＳ１０２）。
また、データパラメータ抽出部１２０は、パターン蓄積部１０００のＰａｔｔｅｒｎテーブルから、対応するＫＰＩ値欄の外部参照を取得する（ステップＳ１０３）。
形式言語生成部１３０は、抽出したパラメータを、対応表の形式言語列に記載されたフォーマットに合うように、形式言語表現（データ）を生成する（ステップＳ１０４）。
次に形式言語増殖部２００が、形式言語表現データを増殖させる動作を、図４と図１０を用いて説明する。以下、形式言語表現データを典型パターンとして、派生設計の形式言語表現データを派生パターンとして記載する。
図１０は、形式言語増殖部２００の動作を示すフローチャートである。
形式言語増殖部２００は、図２４もしくは図３３の対応表に照らし合わせ、典型パターンに対して、形式言語増殖を行い、派生パターンを生成する。
形式言語増殖は、要素増殖部２１０、要素置換部２２０、要素削減部２３０及び統合部２４０が並列的に各々派生設計作成処理を実行し、典型パターンに対する要素の追加し（ステップＳ２０１）、置換（ステップＳ２０２）し、削除（ステップＳ２０３）し、またはそれらを組み合わせて（ステップＳ２０４）、派生パターンを生成する。
最終的に、得られた派生パターンを、パターン蓄積部１０００に格納された図１６に示すＤｅｒｉｖａｂｌｅテーブルの形式言語表現列に記録する（ステップＳ２０５）。
次に、設計抽出部３００が、増殖したスキーマもしくはＸＰａｔｈにマッチする設計を抽出する動作を、図５と図１１、図３２を用いて説明する。
図１１は、設計抽出部３００の動作を示すフローチャートである。
データ型判定部３１０は、図１８のＩｎｓｔａｎｃｅテーブルで「設計図格納場所」欄のファイル名拡張子が一致するＩＤを複数列挙する（ステップＳ３０１）。この場合、ＩＤ１とＩＤ２が同じ拡張子であり、ＩＤ３とＩＤ４が同じ拡張子であるため２ペア列挙される。以降では、ＩｎｓｔａｎｃｅテーブルのＩＤ１およびＩＤ２で共通の拡張子″．ｕｍｌ″について作業を進める。
さらに、データ型判定部３１０は、図２４もしくは図３３の対応表を参照し、拡張子が異なるファイルでも、同じ情報表現となることを認識する。情報表現がＸＭＬとなる拡張子であるｕｍｌ及びｕｍｌ２について、Ｉｎｓｔａｎｃｅテーブルから該当する拡張子のファイルのモデル図を情報表現形式へ変換する候補とする。図１８では、ｕｍｌ２の拡張子を持つ設計は存在しないので、ＩＤ１およびＩＤ２が情報表現形式へと変換される。（ステップＳ３０２）。
次に、データパラメータ抽出部３２０は、ｕｍｌもしくはｕｍｌ２という抽出した拡張子のファイルを選択してそのファイルのパラメータを抽出する（ステップＳ３０３）。
次に、抽出したパラメータをもとに情報表現生成部３３０は、ＸＭＬ形式の情報表現データを生成する（ステップＳ３０４）。
次に、形式言語表現をＸＭＬ Ｓｃｈｅｍａにした場合（図２４の対応表を使用した場合）、合致判定部３４０は、Ｄｅｒｉｖａｂｌｅテーブルの形式言語表現で出現するＸＭＬ Ｓｃｈｅｍａに特有なタグ（タグ名はｅｌｅｍｅｎｔもしくはａｎｙ）の数と、Ｉｎｓｔａｎｃｅテーブルの情報表現のタグの種類数を比較して、前者の数が後者の数以上となる組合せを抽出する（図１１のステップＳ３０５）。形式言語表現をＸＰａｔｈにした場合（図３３の対応表を使用した場合）には、合致判定部３４０は、”／”で区切られた単語の数と、Ｉｎｓｔａｎｃｅテーブルの情報表現のタグ階層数を比較して、前者の数が後者の数以下となる組み合わせを抽出する（図３２のステップＳ３０５１）。
以降の処理では、条件の合致する複数のＸＭＬインスタンスのうち、１つずつ取り出し、１つの派生パターンと比較する。また、１つの派生パターンを選択する際には、派生パターンの中でも、タグ数が少ないものから選択する。
次に、形式言語表現をＸＭＬ Ｓｃｈｅｍａにした場合、合致判定部３４０は、パターンのルート要素のｎａｍｅ属性の値を、ＸＭＬインスタンスのルートタグ名に置き換え、ＸＭＬスキーマを作成する（ステップＳ３０６）。形式言語表現をＸＰａｔｈにした場合には、合格判定部３４０は、パターンのルート要素名にａｘｉｓを追加し、ＸＰａｔｈ式を作成する（ステップＳ３０６１）。
次に、形式言語表現をＸＭＬ Ｓｃｈｅｍａにした場合、合致判定部３４０は、スキーマ検証技術に基づき、情報表現のＸＭＬがパターンから生成したＸＭＬスキーマの形式に一致しているか評価する。合致判定部３４０は、評価の結果、エラーがなければ合格と判定して定量化部４００に判定結果データを通知し、エラーがあれば不合格と判定し、次の候補のＸＭＬインスタンスについて再度評価を繰り返す（ステップＳ３０７）。形式言語表現をＸＰａｔｈにした場合、合致判定部３４０は、情報表現のＸＭＬに対してＸＰａｔｈ式で演算を行い、演算結果の中に要素が１つ以上存在するか評価する。合致判定部３４０は、要素が１つ以上存在すれば合格と判定して定量化部４００に判定結果データを通知し、エラーがあれば不合格と判定し、次の候補のＸＭＬインスタンスについて再度評価を繰り返す（ステップＳ３０７１）。
その後、定量化部４００は、判定結果データを受けて、合格したＸＭＬインスタンスの設計に対してＫＰＩ値を計算する（ステップＳ４００）。
次に定量化部４００が、パターンのＫＰＩ値の抽出、ＸＭＬインスタンスのＫＰＩ値を算出する動作を、図６と図１２を用いて説明する。
図１２は、定量化部４００の動作を示すフローチャートである。
まず、定量化部４００は、パターン蓄積部１０００に格納された図１５に示す「Ｐａｔｔｅｒｎ」テーブルを参照し、「ＫＰＩ値」列から、パターンの価値を算出するためのＫＰＩ ＩＤを取得する（ステップＳ４０１）。
ＫＰＩ ＩＤは、ＫＰＩ算出方式格納部１３００に格納された図２０に示す「ＫＰＩ」テーブルのＩＤ列の値を示している。「ＫＰＩ」テーブルには、ＫＰＩ算出関数と推奨範囲が記載されているため、パターンの価値となるＫＰＩ値は、推奨範囲のＴＡＲＧＥＴプロパティで指定された値を採用するので、定量化部４００は、「ＫＰＩ」テーブルの値を取得する（ステップＳ４０２）。
次に、定量化部４００は、ＸＭＬインスタンスのＫＰＩ値を算出するため、既存システム実行ログ蓄積部１２００に格納された図１９に示す「ＬＯＧ」テーブルから、既存システムのインスタンスＩＤ、設計を運用した時のログファイルの場所、ログファイル中の特定のデータを抽出するための文字列を取得する（ステップＳ４０３）。これによって、インスタンスＩＤとＫＰＩ計算に必要となる文字や数値データが関連づけられる。
定量化部４００は、ＫＰＩ算出方式格納部１３００に格納された「ＫＰＩ＿ＶＡＬＵＥ＿ＦＲＯＭ」テーブル（図２１参照）を参照し、「入力データ」列からログＩＤを取得し、「関数」列から「ＫＰＩ」テーブルのＫＰＩ ＩＤを取得してＫＰＩ算出関数を選択する（ステップＳ４０４）。
定量化部４００は、選択したＫＰＩ算出関数にログファイル中の特定のデータを入力値として適用して、ＸＭＬインスタンスのＫＰＩ値を算出し、ＫＰＩ算出方式格納部１３００に格納された図２２に示す「Ｑｕａｎｔｉｔｙ」テーブルの「スコア」列に格納する（ステップＳ４０５）。
定量化部４００は、パターンと同じＫＰＩを算出するためのログが得られない場合、警告をユーザに対して提示するまた、この作業を繰り返し、１つのパターンにマッチするＸＭＬインスタンスのＫＰＩ値を全て算出する。さらに、複数のパターンについても処理を行う。
次に、選別部５００が、定量化部４００によって得られたＸＭＬインスタンスのＫＰＩ値をもとに、良い設計と悪い設計を選別する動作を、図７と図１３を用いて説明する。
図１３は、選別部５００の動作を示すフローチャートである。
まず、置き換え対象管理部５１０は、Ｑｕａｎｔｉｔｙテーブルを参照し、「比較に利用したＫＰＩ」列で同一の値を持ち、「インスタンス」列の値が異なるものをリストとして抽出してリスト集合データを作成する（ステップＳ５０１）。
置き換え対象管理部５１０は、リスト集合データの中から最もＫＰＩ値の良いインスタンスＩＤを選択する（ステップＳ５０２）。
置き換え対象管理部５１０は、パターン蓄積部１０００に格納された「Ｐｒｏｐｏｓａｌ」テーブル（図１７参照）に、「Ｆｒｏｍ」列にリスト集合データに含まれるインスタンスのＩＤを記載し、「Ｔｏ」列に最もＫＰＩ値の良いスコアを持つインスタンスのＩＤを記載する（ステップＳ５０３）。即ち、良い設計といえる最もＫＰＩ値の高いインスタンスのＩＤをＴｏ列に記載して、悪い設計といえる置き換え対象となるインスタンスのＩＤをＦｒｏｍ列に記載する。
次に、ＲＯＩ計算部５２０は、ＲＯＩ値を次の式（１）で算出する。
ＲＯＩ値＝標準パターンのＫＰＩ／ＸＭＬインスタンスのＫＰＩ＊標準パターンの構成要素数／ＸＭＬインスタンスの構成要素数 ・・・式（１）
続いて、ＲＯＩ計算部５２０は、「Ｐｒｏｐｏｓａｌ」テーブルのＲＯＩ列にスコア比率を記載する。スコア比率は、「Ｆｒｏｍ」列のインスタンスＩＤが持つＲＯＩ値のスコアを分母に、「Ｔｏ」列のインスタンスＩＤが持つＲＯＩ値のスコアを分子とする（ステップＳ５０４）。
次に、等価性検証部６００が、置き換え可能性を判定する動作について、図８と図１４を用いて説明する。
図１４は、等価性検証部６００の動作を示すフローチャートである。
等価性検証部６００は、「Ｐｒｏｐｏｓａｌ」テーブルの「Ｆｒｏｍ」列に記載されたインスタンスＩＤから、「Ｔｏ」列に記載されたインスタンスＩＤに置き換えを実現できるか否か、テストデータを用いて検証する。
まず、テストデータ抽出部６１０は、「Ｐｒｏｐｏｓａｌ」テーブルの「Ｆｒｏｍ」列に記載されたインスタンス（被置換候補）を検証するために準備されたテストデータの中から、パターンにマッチした箇所だけ含むテストケースを抽出する。これを実現するため、既存システムテストデータ蓄積部１４００に格納された図２３に示す「ＴＥＳＴ」テーブルの「インスタンスＩＤ」列から検証するインスタンスを選択し、インスタンスが利用する全てのプロセスファイルを次のように検証する。テストデータ抽出部６１０は、「テストプロセス」列に記載されたファイルの中から、パターンにマッチするサービスのみを呼び出すものを、コードを行単位として文字列マッチングを実施し、その結果を抽出する（ステップＳ６０１）。
同様に、テストデータ抽出部６１０は「Ｐｒｏｐｏｓａｌ」テーブルの「Ｔｏ」列に記載されたインスタンス（置換候補）のために準備されたテストデータの中から、パターンにマッチした箇所だけを含むテストケースを抽出する（ステップＳ６０２）。
テスト実行部６２０は、テストデータ抽出部６１０が抽出したインスタンスＩＤとテストプロセスＩＤを用いて、置き換え先のテストケースに、置き換え元のテストプロセス、置き換え元のプロセス入力データ、置き換え元のプロセス検証データを与え、テストを実行する（ステップＳ６０３）。
さらにテスト実行部６２０は、実行結果を「Ｐｒｏｐｏｓａｌ」テーブルの「ＰＡＳＳ」列に、合格であれば１、不合格であれば０を設定する（ステップＳ６０４）。
次に、本発明の実施の形態の効果について説明する。
本実施の形態のモデル検証システムでは、上記動作を行なうことで、図形式で表現された設計データを形式言語等に変換すると共に形式言語のバリエーションを自動的に増やすことが可能となる。
また、人間が目視して確認するために作成したモデル図同士の比較を、機械的に実施可能となる。その理由は、複数のモデル図を形式言語へ変換し、形式言語上の検査技術もしくは、形式言語上の抽出技術を応用して、機械的に演算できる手順を確立したためである。
加えて、システムの部分的な改善提案を、属人性を排除して行うことが可能となる。その理由は、規定のパターン設計に類似した設計を既存システムの中から抽出し、実行ログから算出したＫＰＩをもとに類似設計を定量的に比較し、優劣をつけるためである。
更に、改善によるリスクと効果を定量的に提示できる。その理由は、改善前のテストデータを、改善後の設計に適用して、テストが合格する数を把握するためである。
また、精度良く既存システムの置換候補箇所と、置換による効果を数値化できる。その理由は、熟練者のオリジナル設計だけでなく、派生設計を自動的に生成し、検証に用いる設計の対象を増やすためである。また、ログを活用することで、非熟練者の設計の中から改善点を有効に探し出すことが可能となる。加えて、派生設計を自動的に生成することで、熟練者への設計負担が軽減される。
次に、本発明の第２の実施の形態について、図面を参照して詳細に説明する。
図２７は、第２の実施の形態における形式言語変換部１００の構成を示すブロック図である。
図２８は、第２の実施の形態における設計抽出部３００の構成を示すブロック図である。
図２７と図２８を参照すると、本発明の第２の実施の形態のモデル検証システムは、第１の実施の形態のモデル検証システムに加え、形式言語変換部１００にデータパラメータ抽出部２１２０及び形式言語生成部２１３０、設計抽出部３００にデータパラメータ抽出部２３２０及び情報表現生成部２３３０を加えて有する。
各部はそれぞれ概略つぎのように動作する。尚、動作の説明は、第１の実施の形態のモデル検証システムの動作と同様の部分は説明を省略し、差分を記載する。
データパラメータ抽出部２１２０は、モデル図であるシーケンス図（図２９参照）からサービスコンポーネント、呼び出し順序に加え、インタフェース名を抽出する（ステップＳ１０２の処理）。
形式言語生成部２１３０は、ＢＰＥＬ２．０で記載された情報表現を検証可能であるＸＭＬスキーマを生成する（ステップＳ１０４の処理）。
データパラメータ抽出部２３２０は、データパラメータ抽出部２１２０と同じ動作をする。
情報表現生成部２３３０は、抽出されたパラメータに基づき、ＢＰＥＬ２．０で記載された情報記述表現データを生成する。
上記動作以外は、第１の実施の形態のモデル検証システムの動作と同様である。
次に、本発明の実施の形態の効果について説明する。
本実施の形態では、ＢＰＥＬ２．０に対応可能で有り、閲覧、検索など、情報の利用履歴を分析し、重要度を選別するように構成されているため、ユーザの追加作業を必要とせず情報を順位づけできる。
図１は、第１の実施の形態のモデル検証システムの構成の一部を示す機能ブロック図である。図２は、第１の実施の形態のモデル検証システムの構成を示す機能ブロック図である。
図１及び図２を参照すると、本発明の第１の実施の形態は、プログラム制御により動作する形式言語変換部１００と、形式言語増殖部２００と、設計抽出部３００と、定量化部４００と、選別部５００と、等価性検証部６００と、パターン蓄積部１０００と、既存システム設計蓄積部１１００と、既存システム実行ログ蓄積部１２００と、ＫＰＩ算出方式格納部１３００と、既存システムテストデータ蓄積部１４００と、対応表蓄積部１５００とから構成されている。
パターン蓄積部１０００には、設計の参考に用いる典型的なモデル図（オブジェクトモデルデータ）が登録（記憶）されている。また、典型的なモデル図から生成された派生設計が登録される。さらに、複数の設計を別の設計に置き換えた場合に得られる効果を示した改善提案が登録される。また、パターン蓄積部１０００には、典型的なモデル図の評価指標となるＫＰＩ値リファレンスが記録される。
既存システム設計蓄積部１１００には、複数の設計情報が格納される。これらの設計情報は、実際に動作しているシステム（既存システム）の設計情報であり、改善の余地がある設計や優れた設計など、様々な完成度を持った設計情報である。
既存システム実行ログ蓄積部１２００には、複数の設計によって動作しているシステムのログが何処に格納されているか、またログの中から重要な情報を抽出するための正規表現が格納されている。
ＫＰＩ算出方式格納部１３００には、ＫＰＩの推奨範囲と、ＫＰＩ値を算出する関数と、関数の入力となるログデータの参照先が格納されている。さらに実際のログを用いて算出したＫＰＩ値を格納する。
既存システムテストデータ蓄積部１４００には、複数の設計の動作確認に利用したテストデータが格納されている。また、既存システムテストデータ蓄積部１４００には、テストケースを実行するために必要な入力データ、実行後に期待される結果を示す検証データが記録される。
対応表蓄積部１５００には、形式言語変換部１００等で参照される形式言語の変換や設計抽出に用いられる対応表が蓄積される。
図３は、形式言語変換部１００の構成を示すブロック図である。形式言語変換部１００は、データ型判定部１１０と、データパラメータ抽出部１２０と、形式言語表現生成部１３０とを含む。
各部はそれぞれ概略つぎのように動作する。
データ型判定部１１０は、パターン蓄積部１０００から設計パターンとして登録されているモデル図が記載されたファイルを読み出し、当該ファイルを拡張子もしくはファイル先頭部に定義された型情報などを識別してその情報に基づいて、適切なデータパラメータ抽出部１２０に転送する。
データパラメータ抽出部１２０は、ファイルの内容からモデル図を特徴づけるパラメータを抽出して形式言語生成部１３０に転送する。パラメータの一例としては、モデルに含まれる要素間の関係や多重度などを挙げることができる。
形式言語生成部１３０は、抽出されたパラメータから、形式言語表現（データ）を生成する。形式言語表現の一例として、ＸＭＬスキーマや、ＸＰａｔｈ、Ｒｅｇｕｌａｒ Ｌａｎｇｕａｇｅ ｄｅｓｃｒｉｐｔｉｏｎ ｆｏｒ ＸＭＬ等が存在する。生成された形式言語で表現されたデータは、形式言語増殖部２００に送られる。
形式言語変換部１００は、データ型判定部１１０によって判定される型の数だけ、データパラメータ抽出部１２０と形式言語表現生成部１３０の組を追加可能な構造であり、将来新しく定義されたモデル図（拡張子や型情報を含む）も対応可能である。
図４は、形式言語増殖部２００の構成を示すブロック図である。形式言語増殖部２００は、要素増殖部２１０と、要素置換部２２０と、要素削減部２３０と、統合部２４０とを含む。
各部はそれぞれ概略つぎのように動作する。
要素増殖部２１０は、形式言語で表現されたデータに、「任意の要素」を示すデータを挿入する。挿入する任意の要素数の上限は、システム利用者が変更できるようになっている。
要素置換部２２０は、形式言語で表現されたデータの一部を、「任意の要素」を示すデータに置き換える。置き換える要素数の上限は、形式言語で表現されたデータサイズに応じて決定される。
要素削減部２３０は、形式言語で表現されたデータの一部を削除する。削除する要素数の上限は、形式言語で表現されたデータサイズに応じて決定される。
統合部２４０は、要素増殖部２１０、要素置換部２２０、要素削減部２３０の結果を組み合わせてデータを生成する。結果の組み合わせは、形式言語で表現されたデータサイズに基づいて行なっても良いし、システム利用者の任意の指示に基づいても良い。
形式言語増殖部２００は、要素増殖部２１０と、要素置換部２２０と、要素削減部２３０と、統合部２４０から生成した全てのデータ（派生形式言語表現データ）と形式言語変換部１００で生成されたオリジナルデータ（形式言語表現データ）を、設計抽出部３００に転送する。
尚、形式言語増殖部２００は、要素増殖部２１０と、要素置換部２２０と、要素削減部２３０と、統合部２４０を全て有せずとも、何れかのみを備える形態でも動作させてもよい。
図５は、設計抽出部３００の構成を示すブロック図である。設計抽出部３００は、データ型判定部３１０と、データパラメータ抽出部３２０と、情報表現生成部３３０と、合致判定部３４０とを含む。
各部はそれぞれ概略次のように動作する。
データ型判定部３１０は、既存システム設計部１１００から１つ設計情報のファイルを取り出し、当該ファイルを拡張子もしくは先頭部に定義された型情報を識別してその情報に基づき、適切なデータパラメータ抽出部３２０に転送する。
データパラメータ抽出部３２０は、ファイルの内容からモデル図を特徴づけるパラメータを抽出する。
情報表現生成部３３０は、抽出されたパラメータに基づき、モデル図を別の情報記述表現でデータを表現する。この情報記述表現は、対応表蓄積部１５００に記録されている対応表を用いて、形式言語表現生成部１３０で生成された形式言語表現によって、検証や要素の抽出などが可能になるように定義された形式に限定する。例えば、形式言語表現がＸＭＬスキーマやＸＰａｔｈであれば、情報記述表現はＸＭＬとする。尚、ＸＭＬスキーマ形式のデータは、ＸＭＬ言語や後述するＢＰＥＬ言語に対して、文法の検査や、文法の一部を抽出して検査することに用いることが可能である。また、ＸＰａｔｈ形式のデータは、ＸＭＬ言語や後述するＢＰＥＬ言語で記載された情報に対して、文章の一部を抽出することに用いることが可能である。
合致判定部３４０は、形式言語で表現されたデータと、情報記述表現で表現されたデータが合致するか否か判定し、その結果（判定結果データ）を定量化部４００に通知するともに、既存システム設計蓄積部１１００に記録する。
図６は、定量化部４００の構成を示すブロック図である。定量化部４００は、合致ペア管理部４１０と、ログ管理部４２０と、ＫＰＩ算出部４３０とを含む。
各部はそれぞれ概略次のように動作する。
合致ペア管理部４１０は、設計抽出部３００で合致すると判定されたデータ（判定結果データ）のパターンＩＤとインスタンスＩＤを記憶する。
ログ管理部４２０は、既存システム実行ログ蓄積部１２００から、インスタンスＩＤにマッチするログを取得する。
ＫＰＩ算出部４３０は、パターンＩＤからパターン蓄積部１０００に記憶されるＫＰＩ値リファレンスをたどり、ＫＰＩ算出方式格納部１３００に格納されたＫＰＩ推奨範囲値を抽出する。また、ＫＰＩ算出部４３０は、同様にＫＰＩ値リファレンスをたどり、ＫＰＩ算出方式格納部１３００に格納されたＫＰＩ算出関数を取得する。また、ＫＰＩ算出部４３０は、マッチしたログをＫＰＩ算出関数に適用して値を算出し、その結果データを選別部５００に転送する。
図７は、選別部５００の構成を示すブロック図である。選別部５００は、置き換え対象管理部５１０と、ＲＯＩ（Ｒｅｔｕｒｎ ｏｎ Ｉｎｖｅｓｔｍｅｎｔ）計算部５２０とを含む。
各部はそれぞれ概略次のように動作する。
置き換え対象管理部５１０は、既存システム設計蓄積部１１００に記録された設計情報の定量化結果（形式評価結果）を参照し、同じパターンを参照しているインスタンス同士を１つのグループとして、定量化部４００から得たＫＰＩ値の大小を比較する。同一グループ内で、最もスコアの高いインスタンスを置き換え先候補（置換候補）として、パターン蓄積部１０００に記録する。また、最高スコア以外のインスタンスを置き換え元候補（被置換候補）として置換候補と関連付けて記録し、候補間関係を記録する。
ＲＯＩ計算部５２０は、置き換え先候補のＫＰＩ値を置き換え元候補のＫＰＩ値で割って比率を求め、置き換えを行なった場合の定量的な効果を算出し、ＲＯＩ値としてパターン蓄積部１０００に記録する。
図８は、等価性検証部６００の構成を示すブロック図である。等価性検証部６００は、テストデータ抽出部６１０と、テスト実行部６２０とを含む。
各部はそれぞれ概略次のように動作する。
テストデータ抽出部６１０は、置き換え元候補のインスタンスのうち、パターンにマッチする部分のみを利用するテストケースを、既存システムテストデータ蓄積部１４００から抽出すると共に、テストケースを実行するために必要な入力データと、実行後に期待される結果を示す検証データを取得する。
テスト実行部６２０は、置き換え元候補それぞれについて入手した入力データと検証データを、置き換え先候補のテストケースに適用してテストを実行し、置換可能であるか否かの結果をパターン蓄積部１０００に記録する。
このように動作させて、最終的に、テスト結果を用いて、改善元のスコアと改善先のスコア比率によって、改善効果を定量的に示す。
次に、図３から図８まで、図９から図１４のフローチャートを参照して本実施の形態のモデル検証システム全体の動作について詳細に説明する。
以下では、扱うモデル図をサービスを呼び出すシーケンス図とし、形式言語表現をＸＭＬスキーマとし、情報記述表現をＸＭＬとする。また、各種記憶手段には、Ｐａｔｔｅｒｎテーブル、Ｄｅｒｉｖａｂｌｅテーブル、Ｐｒｏｐｏｓａｌテーブル、ＫＰＩ＿ＶＡＬＵＥ＿ＦＲＯＭテーブル、Ｑｕａｎｔｉｔｙテーブル、ＫＰＩテーブルテーブル、Ｉｎｓｔａｎｃｅテーブル、ＬＯＧテーブル、及びＴＥＳＴテーブルが格納されており、各種動作に用いられる。
ここで、各テーブルについて説明する。
Ｐａｔｔｅｒｎテーブル（設計パターンテーブル）は、典型的なモデル図の設計データが格納された場所（アドレス）と、その設計の評価指標（ＫＰＩ値）と、形式言語変換部１００でモデル図から生成した形式言語表現の文字列をＩＤで対応付けて格納する。ＫＰＩ値は外部キーであり、ＫＰＩテーブルを参照している。
Ｄｅｒｉｖａｂｌｅテーブル（抽出テーブル）は、形式言語増殖部２００によって増殖された典型的なモデル図の形式言語表現が格納される。また、形式言語表現の元となった派生元パターンもあわせて格納されている。派生元パターンの値は外部キーであり、Ｐａｔｔｅｒｎテーブルを参照している。
Ｐｒｏｐｏｓａｌテーブル（提案テーブル）は、改善すべき設計候補と、改善内容の設計候補を格納する。特に、Ｆｒｏｍ欄に改善すべき候補をＩｎｓｔａｎｃｅテーブルへの外部キーとして記載し、Ｔｏ欄に改善内容の候補をＩｎｓｔａｎｃｅテーブルへの外部キーとして記載する。また、Ｆｒｏｍ欄の設計をＴｏ欄の設計に置き換えた場合に、改善効果を定量的に表現するＲＯＩ欄と、置き換えテストの合否を記録するＰＡＳＳ欄を持つ。
ＫＰＩテーブル（重要業績指標テーブル）は、ＫＰＩを算出する関数と、ＫＰＩの値域、目標値、最低ラインを記載する。
ＫＰＩ＿ＶＡＬＵＥ＿ＦＲＯＭテーブル（重要業績指標関連付テーブル）は、ＫＰＩを算出する関数と、関数の入力となるログデータの関連付けを行う。関数欄にＫＰＩを算出する関数をＫＰＩテーブルへの外部キーとして記載する。また、入力データ欄に関数への入力データとなるＬＯＧテーブルへの外部キーとして記載する。
Ｑｕａｎｔｉｔｙテーブル（定量評価テーブル）は、設計情報をある指標で評価した場合のスコアを記載する。比較に利用したＫＰＩ欄に、ＫＰＩテーブルへの外部キーを記載する。また、インスタンス欄に、インスタンステーブルへの外部キーを記載する。
Ｉｎｓｔａｎｃｅテーブル（実証テーブル）は、設計情報の格納場所と、設計情報を情報言語で表現した文字列と、類似するパターン（設計情報）への参照データが格納される。この参照データは、Ｐａｔｔｅｒｎテーブルへの外部キーである。
ＬＯＧテーブルは、設計情報を元に作成したシステムの動作ログの格納場所と、そのログから抽出すべきデータが正規表現で記載されている。設計情報を示すインスタンスＩＤ欄は、インスタンステーブルへの外部キーとなっている。
ＴＥＳＴテーブルは、設計情報と関連付けて、システムの動作を保障するテストで利用されるプロセスデータ、入力データ、検証データが格納される。設計情報を示すインスタンスＩＤ欄は、インスタンステーブルへの外部キーとなっている。
まず、形式言語変換部１００がモデル図を形式言語に変換する動作を、図３と図９を用いて説明する。
図９は、形式言語変換部１００の動作を示すフローチャートである。
データ型判定部１１０は、入力を受け付けたモデル図が記載されたファイルの拡張子″．ｕｍｌ″を対応表蓄積部１５００に格納されている対応表（図２４もしくは図３３参照）に照らし合わせ、読み込み対応可能か否か判定し、対応可能であるデータをデータパラメータ抽出部１２０に転送する（ステップＳ１０１）。
データパラメータ抽出部１２０は、モデル図であるシーケンス図からサービスコンポーネント、呼び出し順序のパラメータを抽出する（ステップＳ１０２）。
また、データパラメータ抽出部１２０は、パターン蓄積部１０００のＰａｔｔｅｒｎテーブルから、対応するＫＰＩ値欄の外部参照を取得する（ステップＳ１０３）。
形式言語生成部１３０は、抽出したパラメータを、対応表の形式言語列に記載されたフォーマットに合うように、形式言語表現（データ）を生成する（ステップＳ１０４）。
次に形式言語増殖部２００が、形式言語表現データを増殖させる動作を、図４と図１０を用いて説明する。以下、形式言語表現データを典型パターンとして、派生設計の形式言語表現データを派生パターンとして記載する。
図１０は、形式言語増殖部２００の動作を示すフローチャートである。
形式言語増殖部２００は、図２４もしくは図３３の対応表に照らし合わせ、典型パターンに対して、形式言語増殖を行い、派生パターンを生成する。
形式言語増殖は、要素増殖部２１０、要素置換部２２０、要素削減部２３０及び統合部２４０が並列的に各々派生設計作成処理を実行し、典型パターンに対する要素の追加し（ステップＳ２０１）、置換（ステップＳ２０２）し、削除（ステップＳ２０３）し、またはそれらを組み合わせて（ステップＳ２０４）、派生パターンを生成する。
最終的に、得られた派生パターンを、パターン蓄積部１０００に格納された図１６に示すＤｅｒｉｖａｂｌｅテーブルの形式言語表現列に記録する（ステップＳ２０５）。
次に、設計抽出部３００が、増殖したスキーマもしくはＸＰａｔｈにマッチする設計を抽出する動作を、図５と図１１、図３２を用いて説明する。
図１１は、設計抽出部３００の動作を示すフローチャートである。
データ型判定部３１０は、図１８のＩｎｓｔａｎｃｅテーブルで「設計図格納場所」欄のファイル名拡張子が一致するＩＤを複数列挙する（ステップＳ３０１）。この場合、ＩＤ１とＩＤ２が同じ拡張子であり、ＩＤ３とＩＤ４が同じ拡張子であるため２ペア列挙される。以降では、ＩｎｓｔａｎｃｅテーブルのＩＤ１およびＩＤ２で共通の拡張子″．ｕｍｌ″について作業を進める。
さらに、データ型判定部３１０は、図２４もしくは図３３の対応表を参照し、拡張子が異なるファイルでも、同じ情報表現となることを認識する。情報表現がＸＭＬとなる拡張子であるｕｍｌ及びｕｍｌ２について、Ｉｎｓｔａｎｃｅテーブルから該当する拡張子のファイルのモデル図を情報表現形式へ変換する候補とする。図１８では、ｕｍｌ２の拡張子を持つ設計は存在しないので、ＩＤ１およびＩＤ２が情報表現形式へと変換される。（ステップＳ３０２）。
次に、データパラメータ抽出部３２０は、ｕｍｌもしくはｕｍｌ２という抽出した拡張子のファイルを選択してそのファイルのパラメータを抽出する（ステップＳ３０３）。
次に、抽出したパラメータをもとに情報表現生成部３３０は、ＸＭＬ形式の情報表現データを生成する（ステップＳ３０４）。
次に、形式言語表現をＸＭＬ Ｓｃｈｅｍａにした場合（図２４の対応表を使用した場合）、合致判定部３４０は、Ｄｅｒｉｖａｂｌｅテーブルの形式言語表現で出現するＸＭＬ Ｓｃｈｅｍａに特有なタグ（タグ名はｅｌｅｍｅｎｔもしくはａｎｙ）の数と、Ｉｎｓｔａｎｃｅテーブルの情報表現のタグの種類数を比較して、前者の数が後者の数以上となる組合せを抽出する（図１１のステップＳ３０５）。形式言語表現をＸＰａｔｈにした場合（図３３の対応表を使用した場合）には、合致判定部３４０は、”／”で区切られた単語の数と、Ｉｎｓｔａｎｃｅテーブルの情報表現のタグ階層数を比較して、前者の数が後者の数以下となる組み合わせを抽出する（図３２のステップＳ３０５１）。
以降の処理では、条件の合致する複数のＸＭＬインスタンスのうち、１つずつ取り出し、１つの派生パターンと比較する。また、１つの派生パターンを選択する際には、派生パターンの中でも、タグ数が少ないものから選択する。
次に、形式言語表現をＸＭＬ Ｓｃｈｅｍａにした場合、合致判定部３４０は、パターンのルート要素のｎａｍｅ属性の値を、ＸＭＬインスタンスのルートタグ名に置き換え、ＸＭＬスキーマを作成する（ステップＳ３０６）。形式言語表現をＸＰａｔｈにした場合には、合格判定部３４０は、パターンのルート要素名にａｘｉｓを追加し、ＸＰａｔｈ式を作成する（ステップＳ３０６１）。
次に、形式言語表現をＸＭＬ Ｓｃｈｅｍａにした場合、合致判定部３４０は、スキーマ検証技術に基づき、情報表現のＸＭＬがパターンから生成したＸＭＬスキーマの形式に一致しているか評価する。合致判定部３４０は、評価の結果、エラーがなければ合格と判定して定量化部４００に判定結果データを通知し、エラーがあれば不合格と判定し、次の候補のＸＭＬインスタンスについて再度評価を繰り返す（ステップＳ３０７）。形式言語表現をＸＰａｔｈにした場合、合致判定部３４０は、情報表現のＸＭＬに対してＸＰａｔｈ式で演算を行い、演算結果の中に要素が１つ以上存在するか評価する。合致判定部３４０は、要素が１つ以上存在すれば合格と判定して定量化部４００に判定結果データを通知し、エラーがあれば不合格と判定し、次の候補のＸＭＬインスタンスについて再度評価を繰り返す（ステップＳ３０７１）。
その後、定量化部４００は、判定結果データを受けて、合格したＸＭＬインスタンスの設計に対してＫＰＩ値を計算する（ステップＳ４００）。
次に定量化部４００が、パターンのＫＰＩ値の抽出、ＸＭＬインスタンスのＫＰＩ値を算出する動作を、図６と図１２を用いて説明する。
図１２は、定量化部４００の動作を示すフローチャートである。
まず、定量化部４００は、パターン蓄積部１０００に格納された図１５に示す「Ｐａｔｔｅｒｎ」テーブルを参照し、「ＫＰＩ値」列から、パターンの価値を算出するためのＫＰＩ ＩＤを取得する（ステップＳ４０１）。
ＫＰＩ ＩＤは、ＫＰＩ算出方式格納部１３００に格納された図２０に示す「ＫＰＩ」テーブルのＩＤ列の値を示している。「ＫＰＩ」テーブルには、ＫＰＩ算出関数と推奨範囲が記載されているため、パターンの価値となるＫＰＩ値は、推奨範囲のＴＡＲＧＥＴプロパティで指定された値を採用するので、定量化部４００は、「ＫＰＩ」テーブルの値を取得する（ステップＳ４０２）。
次に、定量化部４００は、ＸＭＬインスタンスのＫＰＩ値を算出するため、既存システム実行ログ蓄積部１２００に格納された図１９に示す「ＬＯＧ」テーブルから、既存システムのインスタンスＩＤ、設計を運用した時のログファイルの場所、ログファイル中の特定のデータを抽出するための文字列を取得する（ステップＳ４０３）。これによって、インスタンスＩＤとＫＰＩ計算に必要となる文字や数値データが関連づけられる。
定量化部４００は、ＫＰＩ算出方式格納部１３００に格納された「ＫＰＩ＿ＶＡＬＵＥ＿ＦＲＯＭ」テーブル（図２１参照）を参照し、「入力データ」列からログＩＤを取得し、「関数」列から「ＫＰＩ」テーブルのＫＰＩ ＩＤを取得してＫＰＩ算出関数を選択する（ステップＳ４０４）。
定量化部４００は、選択したＫＰＩ算出関数にログファイル中の特定のデータを入力値として適用して、ＸＭＬインスタンスのＫＰＩ値を算出し、ＫＰＩ算出方式格納部１３００に格納された図２２に示す「Ｑｕａｎｔｉｔｙ」テーブルの「スコア」列に格納する（ステップＳ４０５）。
定量化部４００は、パターンと同じＫＰＩを算出するためのログが得られない場合、警告をユーザに対して提示するまた、この作業を繰り返し、１つのパターンにマッチするＸＭＬインスタンスのＫＰＩ値を全て算出する。さらに、複数のパターンについても処理を行う。
次に、選別部５００が、定量化部４００によって得られたＸＭＬインスタンスのＫＰＩ値をもとに、良い設計と悪い設計を選別する動作を、図７と図１３を用いて説明する。
図１３は、選別部５００の動作を示すフローチャートである。
まず、置き換え対象管理部５１０は、Ｑｕａｎｔｉｔｙテーブルを参照し、「比較に利用したＫＰＩ」列で同一の値を持ち、「インスタンス」列の値が異なるものをリストとして抽出してリスト集合データを作成する（ステップＳ５０１）。
置き換え対象管理部５１０は、リスト集合データの中から最もＫＰＩ値の良いインスタンスＩＤを選択する（ステップＳ５０２）。
置き換え対象管理部５１０は、パターン蓄積部１０００に格納された「Ｐｒｏｐｏｓａｌ」テーブル（図１７参照）に、「Ｆｒｏｍ」列にリスト集合データに含まれるインスタンスのＩＤを記載し、「Ｔｏ」列に最もＫＰＩ値の良いスコアを持つインスタンスのＩＤを記載する（ステップＳ５０３）。即ち、良い設計といえる最もＫＰＩ値の高いインスタンスのＩＤをＴｏ列に記載して、悪い設計といえる置き換え対象となるインスタンスのＩＤをＦｒｏｍ列に記載する。
次に、ＲＯＩ計算部５２０は、ＲＯＩ値を次の式（１）で算出する。
ＲＯＩ値＝標準パターンのＫＰＩ／ＸＭＬインスタンスのＫＰＩ＊標準パターンの構成要素数／ＸＭＬインスタンスの構成要素数 ・・・式（１）
続いて、ＲＯＩ計算部５２０は、「Ｐｒｏｐｏｓａｌ」テーブルのＲＯＩ列にスコア比率を記載する。スコア比率は、「Ｆｒｏｍ」列のインスタンスＩＤが持つＲＯＩ値のスコアを分母に、「Ｔｏ」列のインスタンスＩＤが持つＲＯＩ値のスコアを分子とする（ステップＳ５０４）。
次に、等価性検証部６００が、置き換え可能性を判定する動作について、図８と図１４を用いて説明する。
図１４は、等価性検証部６００の動作を示すフローチャートである。
等価性検証部６００は、「Ｐｒｏｐｏｓａｌ」テーブルの「Ｆｒｏｍ」列に記載されたインスタンスＩＤから、「Ｔｏ」列に記載されたインスタンスＩＤに置き換えを実現できるか否か、テストデータを用いて検証する。
まず、テストデータ抽出部６１０は、「Ｐｒｏｐｏｓａｌ」テーブルの「Ｆｒｏｍ」列に記載されたインスタンス（被置換候補）を検証するために準備されたテストデータの中から、パターンにマッチした箇所だけ含むテストケースを抽出する。これを実現するため、既存システムテストデータ蓄積部１４００に格納された図２３に示す「ＴＥＳＴ」テーブルの「インスタンスＩＤ」列から検証するインスタンスを選択し、インスタンスが利用する全てのプロセスファイルを次のように検証する。テストデータ抽出部６１０は、「テストプロセス」列に記載されたファイルの中から、パターンにマッチするサービスのみを呼び出すものを、コードを行単位として文字列マッチングを実施し、その結果を抽出する（ステップＳ６０１）。
同様に、テストデータ抽出部６１０は「Ｐｒｏｐｏｓａｌ」テーブルの「Ｔｏ」列に記載されたインスタンス（置換候補）のために準備されたテストデータの中から、パターンにマッチした箇所だけを含むテストケースを抽出する（ステップＳ６０２）。
テスト実行部６２０は、テストデータ抽出部６１０が抽出したインスタンスＩＤとテストプロセスＩＤを用いて、置き換え先のテストケースに、置き換え元のテストプロセス、置き換え元のプロセス入力データ、置き換え元のプロセス検証データを与え、テストを実行する（ステップＳ６０３）。
さらにテスト実行部６２０は、実行結果を「Ｐｒｏｐｏｓａｌ」テーブルの「ＰＡＳＳ」列に、合格であれば１、不合格であれば０を設定する（ステップＳ６０４）。
次に、本発明の実施の形態の効果について説明する。
本実施の形態のモデル検証システムでは、上記動作を行なうことで、図形式で表現された設計データを形式言語等に変換すると共に形式言語のバリエーションを自動的に増やすことが可能となる。
また、人間が目視して確認するために作成したモデル図同士の比較を、機械的に実施可能となる。その理由は、複数のモデル図を形式言語へ変換し、形式言語上の検査技術もしくは、形式言語上の抽出技術を応用して、機械的に演算できる手順を確立したためである。
加えて、システムの部分的な改善提案を、属人性を排除して行うことが可能となる。その理由は、規定のパターン設計に類似した設計を既存システムの中から抽出し、実行ログから算出したＫＰＩをもとに類似設計を定量的に比較し、優劣をつけるためである。
更に、改善によるリスクと効果を定量的に提示できる。その理由は、改善前のテストデータを、改善後の設計に適用して、テストが合格する数を把握するためである。
また、精度良く既存システムの置換候補箇所と、置換による効果を数値化できる。その理由は、熟練者のオリジナル設計だけでなく、派生設計を自動的に生成し、検証に用いる設計の対象を増やすためである。また、ログを活用することで、非熟練者の設計の中から改善点を有効に探し出すことが可能となる。加えて、派生設計を自動的に生成することで、熟練者への設計負担が軽減される。
次に、本発明の第２の実施の形態について、図面を参照して詳細に説明する。
図２７は、第２の実施の形態における形式言語変換部１００の構成を示すブロック図である。
図２８は、第２の実施の形態における設計抽出部３００の構成を示すブロック図である。
図２７と図２８を参照すると、本発明の第２の実施の形態のモデル検証システムは、第１の実施の形態のモデル検証システムに加え、形式言語変換部１００にデータパラメータ抽出部２１２０及び形式言語生成部２１３０、設計抽出部３００にデータパラメータ抽出部２３２０及び情報表現生成部２３３０を加えて有する。
各部はそれぞれ概略つぎのように動作する。尚、動作の説明は、第１の実施の形態のモデル検証システムの動作と同様の部分は説明を省略し、差分を記載する。
データパラメータ抽出部２１２０は、モデル図であるシーケンス図（図２９参照）からサービスコンポーネント、呼び出し順序に加え、インタフェース名を抽出する（ステップＳ１０２の処理）。
形式言語生成部２１３０は、ＢＰＥＬ２．０で記載された情報表現を検証可能であるＸＭＬスキーマを生成する（ステップＳ１０４の処理）。
データパラメータ抽出部２３２０は、データパラメータ抽出部２１２０と同じ動作をする。
情報表現生成部２３３０は、抽出されたパラメータに基づき、ＢＰＥＬ２．０で記載された情報記述表現データを生成する。
上記動作以外は、第１の実施の形態のモデル検証システムの動作と同様である。
次に、本発明の実施の形態の効果について説明する。
本実施の形態では、ＢＰＥＬ２．０に対応可能で有り、閲覧、検索など、情報の利用履歴を分析し、重要度を選別するように構成されているため、ユーザの追加作業を必要とせず情報を順位づけできる。
次に、具体的な実施例を用いて第１の実施の形態の動作を説明する。
実施例１では、モデル図をＵＭＬのシーケンス図、形式言語表現をＸＭＬスキーマ、情報記述表現をＸＭＬである場合の実施の形態の動作を説明する。
図２５は、実施例１のスキーマの増殖、定量化を模式的に記した説明図である。図２５の例では、仮に、サービスコンポーネントとしてＡ，Ｂ，Ｃ、呼び出し順序として、Ｂ、Ｃ、Ａが順番に呼び出されるというパラメータが抽出される。また、Ｂから始まりＡで終了する連続処理の時間が５０ｍｓという数値である場合を考える。
モデル検証システムは、対応表にしたがって、入力となるシーケンス図を形式言語表現としてＸＭＬスキーマ形式に変換する。Ｂ、Ｃ、Ａの順番を表すＸＭＬスキーマは下記のとおりとなる。尚、図２５中には、要部のみを示す。
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｎａｍｅ＝″ｐａｔｔｅｒｎ１″＞
＜ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ｂ″／＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ｃ″／＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ａ″／＞
＜／ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜／ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｘｓｄ＞
次に、この標準スキーマに対して、形式言語増殖を行い、派生設計の形式言語表現データとして派生スキーマを生成する。
ここで、ステップＳ２０１によって得られる要素を追加されたパターンを例示すれば、次の２つが挙げられる。
［追加派生パターン１］
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｎａｍｅ＝″ｐａｔｔｅｒｎ２″＞
＜ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ｂ″／＞
＜ｘｓｄ：ａｎｙ＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ｃ″／＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ａ″／＞
＜／ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜／ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｘｓｄ＞
［追加派生パターン２］
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｎａｍｅ＝″ｐａｔｔｅｒｎ３″＞
＜ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ｂ″／＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ｃ″／＞
＜ｘｓｄ：ａｎｙ＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ａ″／＞
＜／ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜／ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｘｓｄ＞
次に、ステップＳ２０２によって得られる要素を変更（置換）されたパターンを例示する。
［置換派生パターン］
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｎａｍｅ＝″ｐａｔｔｅｒｎ４″＞
＜ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ｂ″／＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″ａｎｙ″／＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ａ″／＞
＜／ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜／ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｘｓｄ＞
次に、ステップＳ２０３によって得られる要素を削除されたパターンを例示する。
［削除派生パターン］
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｎａｍｅ＝″ｐａｔｔｅｒｎ５″＞
＜ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ｂ″／＞
＜ｘｓｄ；ｅｌｅｍｅｎｔ ｒｅｆ＝″Ａ″／＞
＜／ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜／ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｘｓｄ＞
次に、ステップＳ２０４によって得られる組み合わせたパターンを例示する。尚、例示のスキーマは、Ｂの削除し、且つ、Ｃをａｎｙに置換したパターンである。
［組み合わせ派生パターン］
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｎａｍｅ＝″ｐａｔｔｅｒｎ６″＞
＜ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜ｘｓｄ：ａｎｙ／＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ａ″／＞
＜／ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜／ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｘｓｄ＞
一方、既存システム設計蓄積部１１００に、拡張子がｕｍｌもしくはｕｍｌ２であるモデル図が、次のように７つ格納されているものとする。
１．Ａ→Ｂ
２．Ｂ→Ａ
３．Ｂ→Ｅ→Ａ
４．Ｂ→Ｄ→Ｃ→Ａ
５．Ｄ→Ｂ→Ｃ→Ａ
６．Ｂ→Ｃ→Ｄ→Ａ
７．Ｂ→Ｃ→Ａ→Ｄ→Ｆ
設計抽出部３００は、それぞれのモデル図の形式を特定してパラメータを抽出し、情報表現生成部３３０によって、情報記述表現データとしてＸＭＬ形式の情報表現データを生成する。
尚、Ａ→Ｂのモデル図は、例えば下記のＸＭＬインスタンスとして表現される。
＜ｐｒｏｃｅｓｓ＞
＜Ａ／＞
＜Ｂ／＞
＜／ｐｒｏｃｅｓｓ＞
また、Ｂ→Ａのモデル図は、例えば下記のＸＭＬインスタンスとして表現される。
＜ｐｒｏｃｅｓｓ＞
＜Ｂ／＞
＜Ａ／＞
＜／ｐｒｏｃｅｓｓ＞
情報表現生成部３３０は、他のモデル図も同様に情報表現データを生成する。
次に、合致判定部３４０によって、ステップＳ２０３で得られた［削除派生パターン］であるｐａｔｔｅｒｎ５と［組合せ派生パターン］であるｐａｔｔｅｒｎ６を基準に比較を行う。例として、ｐａｔｔｅｒｎ５を比較する。
選択されたパターンのルート要素のｎａｍｅ属性の値である″ｐａｔｔｅｒｎ５″を、ＸＭＬインスタンスのルートタグ名である″ｐｒｏｃｅｓｓ″に置き換え、ＸＭＬスキーマを作成（ステップＳ３０６処理）する。
＜ｘｓｄ：ｓｃｈｅｍａ ｘｍｌｎｓ：ｘｓｄ＝″ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／ＸＭＬＳｃｈｅｍａ″＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｎａｍｅ＝″ｐｒｏｃｅｓｓ″＞
＜ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ｂ″／＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ａ″／＞
＜／ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜／ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｘｓｄ：ｅｌｅｍｅｎｔ＞
＜／ｘｓｄ：ｓｃｈｅｍａ＞
次に、各モデル図の情報表現形式のデータを、パターンの形式言語で評価する。評価には、ＸＭＬ文書を読み込みメモリ上でＤｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌに変換するＸＭＬパーサー、例えばＡｐａｃｈｅ Ｘｅｒｃｅｓを用いて、ＸＭＬインスタンスがＸＭＬスキーマの型に沿って記述されているか検証する。
検証の結果、Ｂ→Ａのモデル図は合格し、Ａ→Ｂのモデル図は不合格となる。このため、Ｂ→Ａのモデル図に関するＫＰＩをログから算出する。ここで、Ｂ→Ａのモデル図は合格し、Ａ→Ｂのモデル図は不合格となる理由を述べる。ＸＭＬスキーマのｓｅｑｕｅｎｃｅタグは、順番に内包する要素が出現する制約を示す。この場合、ＢからＡの順番で出現することが制約条件となり、Ａ→Ｂのモデル図は不合格となる。
７つ全てのモデル図について評価が完了していなければ、再度ステップＳ３０４から繰り返す。要素数でグループ分けすると２，３，４，５個の要素を含むグループが４つできるため、４回繰り返す。
次に、Ｂ→Ａのモデル図に関する定量化としてＫＰＩ値を算出するため、まずパターンが保持するＫＰＩ ＩＤをＰａｔｔｅｒｎテーブル（図１５参照）から導出する。標準パターンとして、Ｂ、Ｃ、Ａを順番に呼び出すものが、ＰａｔｔｅｒｎテーブルのＩＤ１で示される設計である。
図１５のＰａｔｔｅｒｎテーブルではＩＤが１である設計Ｘ１．ｕｍｌのＫＰＩ値が、ＫＰＩーブルのＩＤ１に定義されていることが記載されている。図２０のＫＰＩテーブルを参照すると、ＫＰＩ算出関数がｆ（ｓｔｒｉｎｇ［］，ｓｔｒｉｎｇ［］）であることが記載されており、引数として文字列の配列を２つ入力として必要とすることがわかる。
一方、図１８のＩｎｓｔａｎｃｅテーブルを参照し、Ｂ→Ａのモデル図に対応する設計は、ＩｎｓｔａｎｃｅテーブルのＩＤ１であり、ＩＤ１に関するＩｎｓｔａｎｃｅのログは、ＬＯＧテーブルに記載されている。
図１９のＬＯＧテーブルを参照すると、ＩＤ１，ＩＤ２，ＩＤ９のログが、Ｉｎｓｔａｎｃｅ ＩＤ１に関連したログであることがわかる。この場合、ログファイルの格納場所（ファイル場所）は、／ｌｏｇ／ａｐｐ１．ｌｏｇであることがわかる。このログには、下記のような書式のログが記載されている。
２０：３０：００ ｕｒｎ：／ａｂｃ／ｄｅｆ／ｓ１ ｋｅｙ＝ｓｔａｒｔ＿ｔｉｍｅ ｖａｌｕｅ＝６０
２０：３０：０８ ｕｒｎ：／ａｂｃ／ｄｅｆ／ｓ１ ｋｅｙ＝ｉｎｃｉｄｅｎｔ ｖａｌｕｅ＝１０１
２０：３０：３５ ｕｒｎ：／ａｂｃ／ｄｅｆ／ｓ１ ｋｅｙ＝ｅｎｄ＿ｔｉｍｅ ｖａｌｕｅ＝１３５
２０：３０：４０ ｕｒｎ：／ａｂｃ／ｄｅｆ／ｓ１ ｋｅｙ＝ｓｔａｒｔ＿ｔｉｍｅ ｖａｌｕｅ＝１００
２０：３０：４２ ｕｒｎ：／ａｂｃ／ｄｅｆ／ｓ１ ｋｅｙ＝ｉｎｃｉｄｅｎｔ ｖａｌｕｅ＝１０２
２０：３１：１５ ｕｒｎ：／ａｂｃ／ｄｅｆ／ｓ１ ｋｅｙ＝ｅｎｄ＿ｔｉｍｅ ｖａｌｕｅ＝１７５
ＬＯＧテーブルのＩＤ１の抽出マッチ文字列を参照すると、（￥ｗ）や（￥ｄ）というように、括弧で囲まれた箇所が２箇所ある。ログの１行目に適用すると、（￥ｗ）については、″２０：３０：００″が抽出され、（￥ｄ）については″６０″が抽出される。ログは複数行あるため、（￥ｗ）については、｛″２０：３０：００″，″２０：３０：４０″｝という配列に、（￥ｄ）については｛６０，１００｝という配列に格納される。
同様にＬＯＧテーブルのＩＤ２の抽出マッチ文字列を適用し、｛″２０：３０：３５″，″２０：３１：１５″｝と、｛１３５，１７５｝という配列を得る。
ＫＰＩ値の算出には、ＫＰＩ＿ＶＡＬＵＥ＿ＦＲＯＭテーブルに記載された関数と入力データを用いる。このテーブルのＩＤ１には、ｆ（ｓｔｒｉｎｇ［］，ｓｔｒｉｎｇ［］）関数の第一引数に｛″２０：３０：００″，″２０：３０：４０″｝、第二引数に｛″２０：３０：３５″，″２０：３１：１５″｝が与えられる。また、ＫＰＩ値の算出に用いるロジックは、以下のようなロジックを用いればよい。
ｄｅｆ ｆ（ｓｔａｒｔｓ，ｅｎｄｓ）｛
ｖａｒ ｔｏｔａｌ＝０；
ｆｏｒ（ｖａｒ ｉ＝０；ｉ＜ｓｔａｒｔｓ．ｌｅｎｇｔｈ；ｉ＋＋）｛
ｔｏｔａｌ＋＝ｅｎｄｓ［ｉ］−ｓｔａｒｔｓ［ｉ］；
｝
ｒｅｔｕｒｎ ｔｏｔａｌ／ｓｔａｒｔｓ．ｌｅｎｇｔｈ；
｝
これによって、算出されたＢ→Ａのモデル図のＫＰＩ値は３５となる。同様に、パターンにマッチした設計についてログからＫＰＩを算出し、最終的にそれぞれ次のような値（図２５の抽出結果）を得る。
Ｂ→Ａ：３５
Ｂ→Ｅ→Ａ：３５
Ｂ→Ｄ→Ｃ→Ａ：４０
Ｂ→Ｃ→Ｄ→Ａ：５５
要素数の単純さも加味すると、図２６に示すようにＲＯＩ値は下記の通りになる。
Ｂ→Ａ：５０／３５＊３／２
Ｂ→Ｅ→Ａ：５０／３５＊３／３
Ｂ→Ｄ→Ｃ→Ａ：５０／４０＊３／４
Ｂ→Ｃ→Ｄ→Ａ：５０／５５＊３／４
よって、Ｂ→Ｅ→Ａを採用した設計を、Ｂ→Ａに置き換えると、ＲＯＩとして１．５倍の改善価値が生まれることがわかる。
実際に上記のように要素を置き換えても問題ないか検証するために、ＴＥＳＴテーブルを参照し、置き換えテスト（動作検証）を実施する。
Ｂ→Ｅ→Ａが、ＩｎｓｔａｎｃｅテーブルのＩＤ２にあたり、ＴＥＳＴテーブルのＩＤ６からＩＤ８までのテストプロセスで利用したデータの中からＢ→Ｅ→Ａの動作を確認するテストデータのみを選択し、Ｂ→Ａを実行するテストに適用する。当該検証で問題が無ければ、置き換え可能となる。
実施例１では、モデル図をＵＭＬのシーケンス図、形式言語表現をＸＭＬスキーマ、情報記述表現をＸＭＬである場合の実施の形態の動作を説明する。
図２５は、実施例１のスキーマの増殖、定量化を模式的に記した説明図である。図２５の例では、仮に、サービスコンポーネントとしてＡ，Ｂ，Ｃ、呼び出し順序として、Ｂ、Ｃ、Ａが順番に呼び出されるというパラメータが抽出される。また、Ｂから始まりＡで終了する連続処理の時間が５０ｍｓという数値である場合を考える。
モデル検証システムは、対応表にしたがって、入力となるシーケンス図を形式言語表現としてＸＭＬスキーマ形式に変換する。Ｂ、Ｃ、Ａの順番を表すＸＭＬスキーマは下記のとおりとなる。尚、図２５中には、要部のみを示す。
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｎａｍｅ＝″ｐａｔｔｅｒｎ１″＞
＜ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ｂ″／＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ｃ″／＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ａ″／＞
＜／ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜／ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｘｓｄ＞
次に、この標準スキーマに対して、形式言語増殖を行い、派生設計の形式言語表現データとして派生スキーマを生成する。
ここで、ステップＳ２０１によって得られる要素を追加されたパターンを例示すれば、次の２つが挙げられる。
［追加派生パターン１］
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｎａｍｅ＝″ｐａｔｔｅｒｎ２″＞
＜ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ｂ″／＞
＜ｘｓｄ：ａｎｙ＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ｃ″／＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ａ″／＞
＜／ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜／ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｘｓｄ＞
［追加派生パターン２］
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｎａｍｅ＝″ｐａｔｔｅｒｎ３″＞
＜ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ｂ″／＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ｃ″／＞
＜ｘｓｄ：ａｎｙ＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ａ″／＞
＜／ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜／ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｘｓｄ＞
次に、ステップＳ２０２によって得られる要素を変更（置換）されたパターンを例示する。
［置換派生パターン］
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｎａｍｅ＝″ｐａｔｔｅｒｎ４″＞
＜ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ｂ″／＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″ａｎｙ″／＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ａ″／＞
＜／ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜／ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｘｓｄ＞
次に、ステップＳ２０３によって得られる要素を削除されたパターンを例示する。
［削除派生パターン］
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｎａｍｅ＝″ｐａｔｔｅｒｎ５″＞
＜ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ｂ″／＞
＜ｘｓｄ；ｅｌｅｍｅｎｔ ｒｅｆ＝″Ａ″／＞
＜／ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜／ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｘｓｄ＞
次に、ステップＳ２０４によって得られる組み合わせたパターンを例示する。尚、例示のスキーマは、Ｂの削除し、且つ、Ｃをａｎｙに置換したパターンである。
［組み合わせ派生パターン］
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｎａｍｅ＝″ｐａｔｔｅｒｎ６″＞
＜ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜ｘｓｄ：ａｎｙ／＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ａ″／＞
＜／ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜／ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｘｓｄ＞
一方、既存システム設計蓄積部１１００に、拡張子がｕｍｌもしくはｕｍｌ２であるモデル図が、次のように７つ格納されているものとする。
１．Ａ→Ｂ
２．Ｂ→Ａ
３．Ｂ→Ｅ→Ａ
４．Ｂ→Ｄ→Ｃ→Ａ
５．Ｄ→Ｂ→Ｃ→Ａ
６．Ｂ→Ｃ→Ｄ→Ａ
７．Ｂ→Ｃ→Ａ→Ｄ→Ｆ
設計抽出部３００は、それぞれのモデル図の形式を特定してパラメータを抽出し、情報表現生成部３３０によって、情報記述表現データとしてＸＭＬ形式の情報表現データを生成する。
尚、Ａ→Ｂのモデル図は、例えば下記のＸＭＬインスタンスとして表現される。
＜ｐｒｏｃｅｓｓ＞
＜Ａ／＞
＜Ｂ／＞
＜／ｐｒｏｃｅｓｓ＞
また、Ｂ→Ａのモデル図は、例えば下記のＸＭＬインスタンスとして表現される。
＜ｐｒｏｃｅｓｓ＞
＜Ｂ／＞
＜Ａ／＞
＜／ｐｒｏｃｅｓｓ＞
情報表現生成部３３０は、他のモデル図も同様に情報表現データを生成する。
次に、合致判定部３４０によって、ステップＳ２０３で得られた［削除派生パターン］であるｐａｔｔｅｒｎ５と［組合せ派生パターン］であるｐａｔｔｅｒｎ６を基準に比較を行う。例として、ｐａｔｔｅｒｎ５を比較する。
選択されたパターンのルート要素のｎａｍｅ属性の値である″ｐａｔｔｅｒｎ５″を、ＸＭＬインスタンスのルートタグ名である″ｐｒｏｃｅｓｓ″に置き換え、ＸＭＬスキーマを作成（ステップＳ３０６処理）する。
＜ｘｓｄ：ｓｃｈｅｍａ ｘｍｌｎｓ：ｘｓｄ＝″ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／ＸＭＬＳｃｈｅｍａ″＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｎａｍｅ＝″ｐｒｏｃｅｓｓ″＞
＜ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ｂ″／＞
＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝″Ａ″／＞
＜／ｘｓｄ：ｓｅｑｕｅｎｃｅ＞
＜／ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｘｓｄ：ｅｌｅｍｅｎｔ＞
＜／ｘｓｄ：ｓｃｈｅｍａ＞
次に、各モデル図の情報表現形式のデータを、パターンの形式言語で評価する。評価には、ＸＭＬ文書を読み込みメモリ上でＤｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌに変換するＸＭＬパーサー、例えばＡｐａｃｈｅ Ｘｅｒｃｅｓを用いて、ＸＭＬインスタンスがＸＭＬスキーマの型に沿って記述されているか検証する。
検証の結果、Ｂ→Ａのモデル図は合格し、Ａ→Ｂのモデル図は不合格となる。このため、Ｂ→Ａのモデル図に関するＫＰＩをログから算出する。ここで、Ｂ→Ａのモデル図は合格し、Ａ→Ｂのモデル図は不合格となる理由を述べる。ＸＭＬスキーマのｓｅｑｕｅｎｃｅタグは、順番に内包する要素が出現する制約を示す。この場合、ＢからＡの順番で出現することが制約条件となり、Ａ→Ｂのモデル図は不合格となる。
７つ全てのモデル図について評価が完了していなければ、再度ステップＳ３０４から繰り返す。要素数でグループ分けすると２，３，４，５個の要素を含むグループが４つできるため、４回繰り返す。
次に、Ｂ→Ａのモデル図に関する定量化としてＫＰＩ値を算出するため、まずパターンが保持するＫＰＩ ＩＤをＰａｔｔｅｒｎテーブル（図１５参照）から導出する。標準パターンとして、Ｂ、Ｃ、Ａを順番に呼び出すものが、ＰａｔｔｅｒｎテーブルのＩＤ１で示される設計である。
図１５のＰａｔｔｅｒｎテーブルではＩＤが１である設計Ｘ１．ｕｍｌのＫＰＩ値が、ＫＰＩーブルのＩＤ１に定義されていることが記載されている。図２０のＫＰＩテーブルを参照すると、ＫＰＩ算出関数がｆ（ｓｔｒｉｎｇ［］，ｓｔｒｉｎｇ［］）であることが記載されており、引数として文字列の配列を２つ入力として必要とすることがわかる。
一方、図１８のＩｎｓｔａｎｃｅテーブルを参照し、Ｂ→Ａのモデル図に対応する設計は、ＩｎｓｔａｎｃｅテーブルのＩＤ１であり、ＩＤ１に関するＩｎｓｔａｎｃｅのログは、ＬＯＧテーブルに記載されている。
図１９のＬＯＧテーブルを参照すると、ＩＤ１，ＩＤ２，ＩＤ９のログが、Ｉｎｓｔａｎｃｅ ＩＤ１に関連したログであることがわかる。この場合、ログファイルの格納場所（ファイル場所）は、／ｌｏｇ／ａｐｐ１．ｌｏｇであることがわかる。このログには、下記のような書式のログが記載されている。
２０：３０：００ ｕｒｎ：／ａｂｃ／ｄｅｆ／ｓ１ ｋｅｙ＝ｓｔａｒｔ＿ｔｉｍｅ ｖａｌｕｅ＝６０
２０：３０：０８ ｕｒｎ：／ａｂｃ／ｄｅｆ／ｓ１ ｋｅｙ＝ｉｎｃｉｄｅｎｔ ｖａｌｕｅ＝１０１
２０：３０：３５ ｕｒｎ：／ａｂｃ／ｄｅｆ／ｓ１ ｋｅｙ＝ｅｎｄ＿ｔｉｍｅ ｖａｌｕｅ＝１３５
２０：３０：４０ ｕｒｎ：／ａｂｃ／ｄｅｆ／ｓ１ ｋｅｙ＝ｓｔａｒｔ＿ｔｉｍｅ ｖａｌｕｅ＝１００
２０：３０：４２ ｕｒｎ：／ａｂｃ／ｄｅｆ／ｓ１ ｋｅｙ＝ｉｎｃｉｄｅｎｔ ｖａｌｕｅ＝１０２
２０：３１：１５ ｕｒｎ：／ａｂｃ／ｄｅｆ／ｓ１ ｋｅｙ＝ｅｎｄ＿ｔｉｍｅ ｖａｌｕｅ＝１７５
ＬＯＧテーブルのＩＤ１の抽出マッチ文字列を参照すると、（￥ｗ）や（￥ｄ）というように、括弧で囲まれた箇所が２箇所ある。ログの１行目に適用すると、（￥ｗ）については、″２０：３０：００″が抽出され、（￥ｄ）については″６０″が抽出される。ログは複数行あるため、（￥ｗ）については、｛″２０：３０：００″，″２０：３０：４０″｝という配列に、（￥ｄ）については｛６０，１００｝という配列に格納される。
同様にＬＯＧテーブルのＩＤ２の抽出マッチ文字列を適用し、｛″２０：３０：３５″，″２０：３１：１５″｝と、｛１３５，１７５｝という配列を得る。
ＫＰＩ値の算出には、ＫＰＩ＿ＶＡＬＵＥ＿ＦＲＯＭテーブルに記載された関数と入力データを用いる。このテーブルのＩＤ１には、ｆ（ｓｔｒｉｎｇ［］，ｓｔｒｉｎｇ［］）関数の第一引数に｛″２０：３０：００″，″２０：３０：４０″｝、第二引数に｛″２０：３０：３５″，″２０：３１：１５″｝が与えられる。また、ＫＰＩ値の算出に用いるロジックは、以下のようなロジックを用いればよい。
ｄｅｆ ｆ（ｓｔａｒｔｓ，ｅｎｄｓ）｛
ｖａｒ ｔｏｔａｌ＝０；
ｆｏｒ（ｖａｒ ｉ＝０；ｉ＜ｓｔａｒｔｓ．ｌｅｎｇｔｈ；ｉ＋＋）｛
ｔｏｔａｌ＋＝ｅｎｄｓ［ｉ］−ｓｔａｒｔｓ［ｉ］；
｝
ｒｅｔｕｒｎ ｔｏｔａｌ／ｓｔａｒｔｓ．ｌｅｎｇｔｈ；
｝
これによって、算出されたＢ→Ａのモデル図のＫＰＩ値は３５となる。同様に、パターンにマッチした設計についてログからＫＰＩを算出し、最終的にそれぞれ次のような値（図２５の抽出結果）を得る。
Ｂ→Ａ：３５
Ｂ→Ｅ→Ａ：３５
Ｂ→Ｄ→Ｃ→Ａ：４０
Ｂ→Ｃ→Ｄ→Ａ：５５
要素数の単純さも加味すると、図２６に示すようにＲＯＩ値は下記の通りになる。
Ｂ→Ａ：５０／３５＊３／２
Ｂ→Ｅ→Ａ：５０／３５＊３／３
Ｂ→Ｄ→Ｃ→Ａ：５０／４０＊３／４
Ｂ→Ｃ→Ｄ→Ａ：５０／５５＊３／４
よって、Ｂ→Ｅ→Ａを採用した設計を、Ｂ→Ａに置き換えると、ＲＯＩとして１．５倍の改善価値が生まれることがわかる。
実際に上記のように要素を置き換えても問題ないか検証するために、ＴＥＳＴテーブルを参照し、置き換えテスト（動作検証）を実施する。
Ｂ→Ｅ→Ａが、ＩｎｓｔａｎｃｅテーブルのＩＤ２にあたり、ＴＥＳＴテーブルのＩＤ６からＩＤ８までのテストプロセスで利用したデータの中からＢ→Ｅ→Ａの動作を確認するテストデータのみを選択し、Ｂ→Ａを実行するテストに適用する。当該検証で問題が無ければ、置き換え可能となる。
本発明の第２の実施例は、モデル図をＢＰＥＬ言語で表現した場合について、図２９および図３０を参照して、例を交えて説明する。
まず、データ型判定部１１０によって、ファイルの拡張子″．ｓｅｑ″を図２３の対応表に照らし合わせ（ステップＳ１０１）、対応可能か否か判定される。
対応可能であった場合、データパラメータ抽出部２１２０は、シーケンス図からサービスコンポーネント、インタフェース、呼び出し順序のパラメータを抽出する（ステップＳ１０３）。
図２９の例では、サービスコンポーネントとしてＡ，Ｂ，Ｃ、インタフェースとしてｏｐ１，ｏｐ２，ｏｐ３、呼び出し順序としてＡからＢとＡからＣとが並列に呼び出されるというパラメータが抽出される。
情報表現生成部２３３０（図２８参照）に対してこのパラメータを与えると、ＢＰＥＬ形式の情報表現が得られる。以下に、得られるＢＰＥＬ形式の情報表現を示す。
＜ｉｎｖｏｋｅ ｏｐｅｒａｔｉｏｎ＝“ｏｐ１”／＞
＜ｆｌｏｗ＞
＜ｉｎｖｏｋｅ ｏｐｅｒａｔｉｏｎ＝“ｏｐ２”／＞
＜ｉｎｖｏｋｅ ｏｐｅｒａｔｉｏｎ＝“ｏｐ３”／＞
＜／ｆｌｏｗ＞
一方、図２７の形式言語生成部２１３０では、上記の情報表現を検証するためのＸＭＬスキーマが図３０に示すように生成される。実施例１と同様に形式言語増殖部によって、類似のパターンに合致した設計を抽出し、改善することができる。
まず、データ型判定部１１０によって、ファイルの拡張子″．ｓｅｑ″を図２３の対応表に照らし合わせ（ステップＳ１０１）、対応可能か否か判定される。
対応可能であった場合、データパラメータ抽出部２１２０は、シーケンス図からサービスコンポーネント、インタフェース、呼び出し順序のパラメータを抽出する（ステップＳ１０３）。
図２９の例では、サービスコンポーネントとしてＡ，Ｂ，Ｃ、インタフェースとしてｏｐ１，ｏｐ２，ｏｐ３、呼び出し順序としてＡからＢとＡからＣとが並列に呼び出されるというパラメータが抽出される。
情報表現生成部２３３０（図２８参照）に対してこのパラメータを与えると、ＢＰＥＬ形式の情報表現が得られる。以下に、得られるＢＰＥＬ形式の情報表現を示す。
＜ｉｎｖｏｋｅ ｏｐｅｒａｔｉｏｎ＝“ｏｐ１”／＞
＜ｆｌｏｗ＞
＜ｉｎｖｏｋｅ ｏｐｅｒａｔｉｏｎ＝“ｏｐ２”／＞
＜ｉｎｖｏｋｅ ｏｐｅｒａｔｉｏｎ＝“ｏｐ３”／＞
＜／ｆｌｏｗ＞
一方、図２７の形式言語生成部２１３０では、上記の情報表現を検証するためのＸＭＬスキーマが図３０に示すように生成される。実施例１と同様に形式言語増殖部によって、類似のパターンに合致した設計を抽出し、改善することができる。
本発明の第３の実施例は、形式言語表現にＸＰａｔｈ式を採用した場合について、例を交えて説明する。
図３１は、実施例３のＸＰａｔｈ式の増殖を模式的に記した説明図である。図３１の例では、仮に、サービスコンポーネントとしてＡ，Ｂ，Ｃ、呼び出し順序として、Ｂ、Ｃ、Ａが順番に呼び出されるというパラメータが抽出される。
モデル検証システムは、対応表（図３３参照）にしたがって、入力となるシーケンス図を形式言語表現としてＸＰａｔｈ形式に変換する。Ｂ、Ｃ、Ａの順番を表すＸＰａｔｈ式は下記のとおりとなる。尚、図３１中には、要部のみを示す。
／ｄｅｓｃｅｎｄａｎｔ：：Ｂ／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：Ｃ／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：Ａ
次に、この標準ＸＰａｔｈ式に対して、形式言語増殖を行い、派生設計の形式言語表現データとして派生ＸＰａｔｈ式を生成する。
ここで、ステップＳ２０１によって得られる要素を追加されたパターンを例示すれば、次の２つが挙げられる。
［ＸＰａｔｈ追加派生パターン１］
／ｄｅｓｃｅｎｄａｎｔ：：Ｂ／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：＊／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：Ｃ／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：Ａ
［ＸＰａｔｈ追加派生パターン２］
／ｄｅｓｃｅｎｄａｎｔ：：Ｂ／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：Ｃ／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：＊／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：Ａ
次に、ステップＳ２０２によって得られる要素を変更（置換）されたパターンを例示する。
［ＸＰａｔｈ置換派生パターン］
／ｄｅｓｃｅｎｄａｎｔ：：Ｂ／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：＊／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：Ａ
次に、ステップＳ２０３によって得られる要素を削除されたパターンを例示する。
［ＸＰａｔｈ削除派生パターン］
／ｄｅｓｃｅｎｄａｎｔ：：Ｂ／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：Ａ
次に、ステップＳ２０４によって得られる組み合わせたパターンを例示する。
尚、例示のＸＰａｔｈ式は、Ｂを削除し、且つ、Ｃを＊に置換したパターンである。
／ｄｅｓｃｅｎｄａｎｔ：：＊／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：Ａ
なお、各ＸＰａｔｈ式では、ｄｅｓｃｅｎｄａｎｔの代わりに、ｄｅｓｃｅｎｄａｎｔ−ｃｈｉｌｄを利用してもよい。また、意味的に等価な式、例えば、
／ｄｅｓｃｅｎｄａｎｔ：：Ｂ／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：Ａ
に対して、
／ｄｅｓｃｅｎｄａｎｔ：：Ａ／ｐｒｅｃｅｄｉｎｇ−ｓｉｂｌｉｎｇ：：Ｂ
を利用してもよい。
一方、実施例１と同様にシステム設計蓄積部１１００からモデル図をＸＭＬ形式の情報表現データを生成する。例えば、Ａ→Ｂのモデル図は、例えば下記のＸＭＬインスタンスとして表現される。
＜ｐｒｏｃｅｓｓ＞
＜Ａ／＞
＜Ｂ／＞
＜／ｐｒｏｃｅｓｓ＞
また、Ｂ→Ａのモデル図は、例えば下記のＸＭＬインスタンスとして表現される。
＜ｐｒｏｃｅｓｓ＞
＜Ｂ／＞
＜Ａ／＞
＜／ｐｒｏｃｅｓｓ＞
次に、合致判定部３４０によって、ステップＳ２０３で得られた［ＸＰａｔｈ削除派生パターン］のＸＰａｔｈ式で２つのＸＭＬインスタンスを評価する。評価には、ＸＭＬ文書を読みメモリ上でＤｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌに変換し、与えられたＸＰａｔｈ式で評価をおこなうプロセッサ、例えばＡｐａｃｈｅ Ｘａｌａｎを用いて検証する。
検証の結果、Ｂ→Ａのモデル図は合格し、Ａ→Ｂのモデル図は不合格となる。ここで、Ｂ→Ａのモデル図は合格し、Ａ→Ｂのモデル図は不合格となる理由を述べる。ＸＰａｔｈ式の軸ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇは、順番に要素が出現するという制約を示す。この場合、ＢからＡの順番で出現することが制約条件となり、Ａ→Ｂのモデル図は不合格となる。
以上、上記実施の形態および実施例の説明で示したように、本発明によれば、図形式で表現された設計データを形式言語に変換し、形式言語のバリエーションを自動的に増やすことで、形式言語の変換元であるオリジナル設計と、オリジナルの設計と異なる派生設計を自動的に収集してモデル検証を行なえるモデル検証システムを提供できる。
当該モデル検証システムを用いれば、既存システムを実現した設計情報から、複数のシステムの設計プログラムと比較しながら、良い設計のプログラムを判定して有効に利用することが可能となる。
また、いったん良い設計として蓄積された設計も、技術の進展とともに陳腐化するため、蓄積された良い設計と新しい技術で設計されたものを比較して、どちらがより良い設計であるのか適宜判定することが可能となる。同様に、システム毎に変化する良い設計の条件に合致する設計を判定することが可能となる。
さらに設計の判定を人の主観に頼らずに機械的に実行することで、属人性を排除し、比較の数値化や、比較時間の削減、判定漏れを無くすことが可能となる。
加えて、既存システムにおけるモデル設計の改善に対する費用対効果（投資対効果）を数値で表示可能になる。
尚、上記モデル検証システムの各部は、ハードウェア及びソフトウェアの組み合わせを用いて実現する。具体的には、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）にモデル検証プログラムが展開され、当該プログラムに基づいて制御部（ＣＰＵ）等のハードウェアを動作させることによって、各部および各種手段を実現する。また、前記プログラムは、記憶媒体に記録されて頒布されても良い。当該記録媒体に記録されたプログラムは、有線、無線、又は記録媒体そのものを介して、ＨＤＤ等の補助記憶装置に読込まれ、制御部等を動作させる。
また、本発明の具体的な構成は前述の実施の形態に限られるものではない。構成や動作は、発明の要旨を逸脱しない範囲の変更があってもこの発明に含まれる。
具体的な一例としては、例えば、図３４に示す様に一般的なコンピュータを用いてモデル検証システムを構成できる。当該コンピュータでは、各プログラムが協働して、形式言語データおよび派生設計データを生成し、各種検証を行ない、リファクタリングされた設計データ（再構築されたプログラムデータ）を出力する。出力された設計データは、システムに組み込まれ、リファクタリング後システムとして動作する。当該システムは、リファクタリング前システムに対して、処理速度の向上や必要リソースの低減などの効果を有する。
また、別の例では、一般的なサーバを用いてモデル検証システムを実現できる。サーバ上で構築されたモデル検証システムは、ネットワークを介して接続された既存システムの設計が格納されたデータベース等と接続し、補助記憶装置に記憶された各種プログラムがＲＡＭに展開されて制御部に読込まれることによって、モデル検証システムとして動作する。制御部は、ＲＡＭに読込まれた各種プログラムに基づいて、形式言語変換手段、形式言語増殖手段、設計抽出手段、定量化手段、選別手段、等価性検証手段などとして機能する。また、パターン蓄積部、既存システム設計蓄積部、既存システム実行ログ蓄積部および既存システムテストデータ蓄積部を外部データベースに設け、対応表蓄積部とＫＰＩ算出方式格納部を内蔵の補助記憶装置に設けて、動作させる。
モデル検証システムとして動作するサーバは、入力部やネットワークインタフェースを介して選択された熟練者などの作成した評価の基準となるモデル図データ（オリジナルデータ）を、外部データベースから取得し、所定の形式言語の表現形式に基づく形式言語表現データに変換し、形式言語での構成要素及び／又は属性情報に、修正を加えて仮想的に派生設計の形式言語表現データを生成する。サーバは、生成したデータを用いて、既存の設計済みデータであるモデル図データを、生成された形式言語表現データの表現形式に対応する情報表現形式の情報記述表現データに変換し、その合致度を判定する。サーバは、合致度を判定して合致するデータに関し、既存設計のログデータを用いて、ＫＰＩ値を算出して外部データベースに記憶し、評価の定量化を図る。その後、サーバは、定量化したデータのＫＰＩ値に基づき、良い設計を置換候補として、良い設計より値が悪かった設計を被置換候補として、置換を検討する候補を選別して操作者に提示して、既存設計のデータを有効利用すると共に、置換の検討価値が高い既存システムを識別可能とする。その後、サーバは、テストデータを用いて、置換の検討を行なう置換候補と被置換候補と置換による不具合や整合性の動作検証を行なう。
上記実施の形態を別の表現で説明すれば、モデル検証システムとして動作する情報処理システムは、モデル検証プログラムを記憶する記憶部と、外部データベースと通信可能とするネットワークインタフェースと、プログラムに基づいて動作する制御部とを備え、前記モデル検証プログラムは、前記制御部を、人間の目視に対応する形態に作成されたコンピュータプログラムの設計を示すモデル図データを、所定の形式言語の表現形式に基づく形式言語表現データに変換する形式言語変換手段と、前記形式言語変換手段によって変換した前記形式言語表現データに対して、前記形式言語での構成要素及び／又は属性情報に、修正を加えて派生設計の形式言語表現データを生成する形式言語増殖手段として機能させる。
また、モデル検証プログラムは、制御部を機能させ、形式言語変換手段を、前記モデル図データを拡張子及び／又はファイル先頭部に定義された型情報に基づいて、変換する形式言語の表現形式を判定するデータ型判定手段と、前記データ型判定手段で判定した形式言語の特徴から、前記モデル図データから当該モデル図を特徴づけるパラメータを抽出するデータパラメータ抽出手段と、前記データパラメータ抽出手段で抽出されたパラメータに基づき、形式言語表現データを生成する形式言語生成手段として動作させる。
また、モデル検証プログラムは、制御部を機能させ、形式言語増殖手段を、前記形式言語表現データに対して、任意の構成要素及び／又は属性情報を示すデータを挿入して、派生設計の形式言語表現データを生成する要素増殖手段、前記形式言語表現データの一部を、任意の構成要素及び／又は属性情報を示すデータに置換して、派生設計の形式言語表現データを生成する要素置換手段、前記形式言語表現データの一部である任意の構成要素及び／又は属性情報を示すデータを削除して、派生設計の形式言語表現データを生成する要素削減手段、前記要素増殖手段、前記要素置換手段および前記要素削減手段の出力結果を組み合わせて、派生設計の形式言語表現データを生成する統合手段の何れか又は全てをとして機能させる。
また、モデル検証プログラムは、制御部を、既存の設計済みデータであるモデル図データを、前記形式言語変換手段で変換された形式言語表現データの表現形式に対応する情報表現形式の情報記述表現データに変換すると共に、前記形式言語表現データと前記情報記述表現データとの合致を判定する設計抽出手段として動作させる。
また、モデル検証プログラムは、制御部を、前記合致判定手段での合致結果に基づき、ＫＰＩ推奨範囲値とＫＰＩ算出関数と既存設計ログデータを取得し、合致した前記情報記述表現データのＫＰＩ値を算出する定量化手段として動作させる。
また、モデル検証プログラムは、制御部を、前記定量化手段によって得られた前記情報記述表現データのＫＰＩ値に基づき、置換候補と被置換候補を選別する選別手段として動作させる。このとき、選別して整列された設計と、形式言語変換部で得られたオリジナル設計を比較した結果として関連付けられた置換候補と被置換候補を、パターン蓄積部にモデル図に逆変換して格納するようにしても良い。
また、モデル検証プログラムは、制御部を、既存システムテストデータ蓄積部に格納されたテストデータを用いて、前記選別手段による前記置換候補と前記被置換候補との選別結果の動作検証を行なう等価性検証手段として動作させる。このとき、既存システムテストデータ蓄積部から、リンク元のテストデータを取得し、リンク先の設計に対してテストを実施して、テストが通らなかったリンク元はリンク先を変更し、再度新しいリンク先に対してリンク元データを与えテストを実施する。また、リンク先を変更してテストを実施しても、テストが通らなかったリンク元は改善できないものとしてマークし、パターン蓄積部にその結果を格納するようにしても良い。また、最終的に得られたリンク元の設計は、リンク先の設計で置き換えることが、等価性検証手段で保障されているため、リンク元の設計を含む既存システムを、リンク先の設計で改善するように、既存システムを提供した顧客に対して、改善策を数値化した効果と共に提案することが可能となる。これは、定量化手段でリンク元とリンク先の設計をＫＰＩの値で整列させているため、改善効果を数値で表現できるためである。このとき、改善のための投資と、見返りの効果がはっきりと数値で表現でき、システムの改善の提案に顕著な効果もたらす。
上記モデル検証システムは、形式言語表現データとして、少なくとも、ＸＭＬ言語及び／又はＢＰＥＬ言語に対して、文法検査及び抽出検査に用いるＸＭＬスキーマ形式のデータまたは文章の一部を抽出するＸＰａｔｈ形式のデータを用いることが可能であり、加えて、ＲＯＩの数値化を｛ＲＯＩ値＝標準パターンのＫＰＩ／ＸＭＬインスタンスのＫＰＩ＊標準パターンの構成要素数／ＸＭＬインスタンスの構成要素数｝の数式を用いるので、既存のシステム全般に対して、設計モデルの検証が可能である。
加えて、モデル検証システムは、熟練者でも発生してしまう癖や偏りを排除し、既存システムのリファクタリングを、リソースの削減や処理時間の短縮などの多くのパラメータに対して、真に顧客の望む評価形態で行なえる。即ち、既存システムのプログラムを自動的に正当に評価して可能であれば置換や修正する仕組みと共に、派生設計を自動的に生成することで熟練者のサポートする仕組みとなる。
本発明によれば、電子データとして設計データが複数格納されているデータベースから、類似のものを探し出す用途や、ログデータを利用して類似の設計に優劣をつけ、設計の改善を行うといった用途に適用可能である。
この出願は、２００９年５月１２日に出願された日本出願特願２００９−１１５２７０号、および２００９年９月３日に出願された日本出願特願２００９−２０３２９５号を基礎とする優先権を主張し、その開示の全てをここに取り込む。
図３１は、実施例３のＸＰａｔｈ式の増殖を模式的に記した説明図である。図３１の例では、仮に、サービスコンポーネントとしてＡ，Ｂ，Ｃ、呼び出し順序として、Ｂ、Ｃ、Ａが順番に呼び出されるというパラメータが抽出される。
モデル検証システムは、対応表（図３３参照）にしたがって、入力となるシーケンス図を形式言語表現としてＸＰａｔｈ形式に変換する。Ｂ、Ｃ、Ａの順番を表すＸＰａｔｈ式は下記のとおりとなる。尚、図３１中には、要部のみを示す。
／ｄｅｓｃｅｎｄａｎｔ：：Ｂ／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：Ｃ／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：Ａ
次に、この標準ＸＰａｔｈ式に対して、形式言語増殖を行い、派生設計の形式言語表現データとして派生ＸＰａｔｈ式を生成する。
ここで、ステップＳ２０１によって得られる要素を追加されたパターンを例示すれば、次の２つが挙げられる。
［ＸＰａｔｈ追加派生パターン１］
／ｄｅｓｃｅｎｄａｎｔ：：Ｂ／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：＊／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：Ｃ／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：Ａ
［ＸＰａｔｈ追加派生パターン２］
／ｄｅｓｃｅｎｄａｎｔ：：Ｂ／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：Ｃ／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：＊／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：Ａ
次に、ステップＳ２０２によって得られる要素を変更（置換）されたパターンを例示する。
［ＸＰａｔｈ置換派生パターン］
／ｄｅｓｃｅｎｄａｎｔ：：Ｂ／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：＊／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：Ａ
次に、ステップＳ２０３によって得られる要素を削除されたパターンを例示する。
［ＸＰａｔｈ削除派生パターン］
／ｄｅｓｃｅｎｄａｎｔ：：Ｂ／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：Ａ
次に、ステップＳ２０４によって得られる組み合わせたパターンを例示する。
尚、例示のＸＰａｔｈ式は、Ｂを削除し、且つ、Ｃを＊に置換したパターンである。
／ｄｅｓｃｅｎｄａｎｔ：：＊／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：Ａ
なお、各ＸＰａｔｈ式では、ｄｅｓｃｅｎｄａｎｔの代わりに、ｄｅｓｃｅｎｄａｎｔ−ｃｈｉｌｄを利用してもよい。また、意味的に等価な式、例えば、
／ｄｅｓｃｅｎｄａｎｔ：：Ｂ／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：Ａ
に対して、
／ｄｅｓｃｅｎｄａｎｔ：：Ａ／ｐｒｅｃｅｄｉｎｇ−ｓｉｂｌｉｎｇ：：Ｂ
を利用してもよい。
一方、実施例１と同様にシステム設計蓄積部１１００からモデル図をＸＭＬ形式の情報表現データを生成する。例えば、Ａ→Ｂのモデル図は、例えば下記のＸＭＬインスタンスとして表現される。
＜ｐｒｏｃｅｓｓ＞
＜Ａ／＞
＜Ｂ／＞
＜／ｐｒｏｃｅｓｓ＞
また、Ｂ→Ａのモデル図は、例えば下記のＸＭＬインスタンスとして表現される。
＜ｐｒｏｃｅｓｓ＞
＜Ｂ／＞
＜Ａ／＞
＜／ｐｒｏｃｅｓｓ＞
次に、合致判定部３４０によって、ステップＳ２０３で得られた［ＸＰａｔｈ削除派生パターン］のＸＰａｔｈ式で２つのＸＭＬインスタンスを評価する。評価には、ＸＭＬ文書を読みメモリ上でＤｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌに変換し、与えられたＸＰａｔｈ式で評価をおこなうプロセッサ、例えばＡｐａｃｈｅ Ｘａｌａｎを用いて検証する。
検証の結果、Ｂ→Ａのモデル図は合格し、Ａ→Ｂのモデル図は不合格となる。ここで、Ｂ→Ａのモデル図は合格し、Ａ→Ｂのモデル図は不合格となる理由を述べる。ＸＰａｔｈ式の軸ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇは、順番に要素が出現するという制約を示す。この場合、ＢからＡの順番で出現することが制約条件となり、Ａ→Ｂのモデル図は不合格となる。
以上、上記実施の形態および実施例の説明で示したように、本発明によれば、図形式で表現された設計データを形式言語に変換し、形式言語のバリエーションを自動的に増やすことで、形式言語の変換元であるオリジナル設計と、オリジナルの設計と異なる派生設計を自動的に収集してモデル検証を行なえるモデル検証システムを提供できる。
当該モデル検証システムを用いれば、既存システムを実現した設計情報から、複数のシステムの設計プログラムと比較しながら、良い設計のプログラムを判定して有効に利用することが可能となる。
また、いったん良い設計として蓄積された設計も、技術の進展とともに陳腐化するため、蓄積された良い設計と新しい技術で設計されたものを比較して、どちらがより良い設計であるのか適宜判定することが可能となる。同様に、システム毎に変化する良い設計の条件に合致する設計を判定することが可能となる。
さらに設計の判定を人の主観に頼らずに機械的に実行することで、属人性を排除し、比較の数値化や、比較時間の削減、判定漏れを無くすことが可能となる。
加えて、既存システムにおけるモデル設計の改善に対する費用対効果（投資対効果）を数値で表示可能になる。
尚、上記モデル検証システムの各部は、ハードウェア及びソフトウェアの組み合わせを用いて実現する。具体的には、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）にモデル検証プログラムが展開され、当該プログラムに基づいて制御部（ＣＰＵ）等のハードウェアを動作させることによって、各部および各種手段を実現する。また、前記プログラムは、記憶媒体に記録されて頒布されても良い。当該記録媒体に記録されたプログラムは、有線、無線、又は記録媒体そのものを介して、ＨＤＤ等の補助記憶装置に読込まれ、制御部等を動作させる。
また、本発明の具体的な構成は前述の実施の形態に限られるものではない。構成や動作は、発明の要旨を逸脱しない範囲の変更があってもこの発明に含まれる。
具体的な一例としては、例えば、図３４に示す様に一般的なコンピュータを用いてモデル検証システムを構成できる。当該コンピュータでは、各プログラムが協働して、形式言語データおよび派生設計データを生成し、各種検証を行ない、リファクタリングされた設計データ（再構築されたプログラムデータ）を出力する。出力された設計データは、システムに組み込まれ、リファクタリング後システムとして動作する。当該システムは、リファクタリング前システムに対して、処理速度の向上や必要リソースの低減などの効果を有する。
また、別の例では、一般的なサーバを用いてモデル検証システムを実現できる。サーバ上で構築されたモデル検証システムは、ネットワークを介して接続された既存システムの設計が格納されたデータベース等と接続し、補助記憶装置に記憶された各種プログラムがＲＡＭに展開されて制御部に読込まれることによって、モデル検証システムとして動作する。制御部は、ＲＡＭに読込まれた各種プログラムに基づいて、形式言語変換手段、形式言語増殖手段、設計抽出手段、定量化手段、選別手段、等価性検証手段などとして機能する。また、パターン蓄積部、既存システム設計蓄積部、既存システム実行ログ蓄積部および既存システムテストデータ蓄積部を外部データベースに設け、対応表蓄積部とＫＰＩ算出方式格納部を内蔵の補助記憶装置に設けて、動作させる。
モデル検証システムとして動作するサーバは、入力部やネットワークインタフェースを介して選択された熟練者などの作成した評価の基準となるモデル図データ（オリジナルデータ）を、外部データベースから取得し、所定の形式言語の表現形式に基づく形式言語表現データに変換し、形式言語での構成要素及び／又は属性情報に、修正を加えて仮想的に派生設計の形式言語表現データを生成する。サーバは、生成したデータを用いて、既存の設計済みデータであるモデル図データを、生成された形式言語表現データの表現形式に対応する情報表現形式の情報記述表現データに変換し、その合致度を判定する。サーバは、合致度を判定して合致するデータに関し、既存設計のログデータを用いて、ＫＰＩ値を算出して外部データベースに記憶し、評価の定量化を図る。その後、サーバは、定量化したデータのＫＰＩ値に基づき、良い設計を置換候補として、良い設計より値が悪かった設計を被置換候補として、置換を検討する候補を選別して操作者に提示して、既存設計のデータを有効利用すると共に、置換の検討価値が高い既存システムを識別可能とする。その後、サーバは、テストデータを用いて、置換の検討を行なう置換候補と被置換候補と置換による不具合や整合性の動作検証を行なう。
上記実施の形態を別の表現で説明すれば、モデル検証システムとして動作する情報処理システムは、モデル検証プログラムを記憶する記憶部と、外部データベースと通信可能とするネットワークインタフェースと、プログラムに基づいて動作する制御部とを備え、前記モデル検証プログラムは、前記制御部を、人間の目視に対応する形態に作成されたコンピュータプログラムの設計を示すモデル図データを、所定の形式言語の表現形式に基づく形式言語表現データに変換する形式言語変換手段と、前記形式言語変換手段によって変換した前記形式言語表現データに対して、前記形式言語での構成要素及び／又は属性情報に、修正を加えて派生設計の形式言語表現データを生成する形式言語増殖手段として機能させる。
また、モデル検証プログラムは、制御部を機能させ、形式言語変換手段を、前記モデル図データを拡張子及び／又はファイル先頭部に定義された型情報に基づいて、変換する形式言語の表現形式を判定するデータ型判定手段と、前記データ型判定手段で判定した形式言語の特徴から、前記モデル図データから当該モデル図を特徴づけるパラメータを抽出するデータパラメータ抽出手段と、前記データパラメータ抽出手段で抽出されたパラメータに基づき、形式言語表現データを生成する形式言語生成手段として動作させる。
また、モデル検証プログラムは、制御部を機能させ、形式言語増殖手段を、前記形式言語表現データに対して、任意の構成要素及び／又は属性情報を示すデータを挿入して、派生設計の形式言語表現データを生成する要素増殖手段、前記形式言語表現データの一部を、任意の構成要素及び／又は属性情報を示すデータに置換して、派生設計の形式言語表現データを生成する要素置換手段、前記形式言語表現データの一部である任意の構成要素及び／又は属性情報を示すデータを削除して、派生設計の形式言語表現データを生成する要素削減手段、前記要素増殖手段、前記要素置換手段および前記要素削減手段の出力結果を組み合わせて、派生設計の形式言語表現データを生成する統合手段の何れか又は全てをとして機能させる。
また、モデル検証プログラムは、制御部を、既存の設計済みデータであるモデル図データを、前記形式言語変換手段で変換された形式言語表現データの表現形式に対応する情報表現形式の情報記述表現データに変換すると共に、前記形式言語表現データと前記情報記述表現データとの合致を判定する設計抽出手段として動作させる。
また、モデル検証プログラムは、制御部を、前記合致判定手段での合致結果に基づき、ＫＰＩ推奨範囲値とＫＰＩ算出関数と既存設計ログデータを取得し、合致した前記情報記述表現データのＫＰＩ値を算出する定量化手段として動作させる。
また、モデル検証プログラムは、制御部を、前記定量化手段によって得られた前記情報記述表現データのＫＰＩ値に基づき、置換候補と被置換候補を選別する選別手段として動作させる。このとき、選別して整列された設計と、形式言語変換部で得られたオリジナル設計を比較した結果として関連付けられた置換候補と被置換候補を、パターン蓄積部にモデル図に逆変換して格納するようにしても良い。
また、モデル検証プログラムは、制御部を、既存システムテストデータ蓄積部に格納されたテストデータを用いて、前記選別手段による前記置換候補と前記被置換候補との選別結果の動作検証を行なう等価性検証手段として動作させる。このとき、既存システムテストデータ蓄積部から、リンク元のテストデータを取得し、リンク先の設計に対してテストを実施して、テストが通らなかったリンク元はリンク先を変更し、再度新しいリンク先に対してリンク元データを与えテストを実施する。また、リンク先を変更してテストを実施しても、テストが通らなかったリンク元は改善できないものとしてマークし、パターン蓄積部にその結果を格納するようにしても良い。また、最終的に得られたリンク元の設計は、リンク先の設計で置き換えることが、等価性検証手段で保障されているため、リンク元の設計を含む既存システムを、リンク先の設計で改善するように、既存システムを提供した顧客に対して、改善策を数値化した効果と共に提案することが可能となる。これは、定量化手段でリンク元とリンク先の設計をＫＰＩの値で整列させているため、改善効果を数値で表現できるためである。このとき、改善のための投資と、見返りの効果がはっきりと数値で表現でき、システムの改善の提案に顕著な効果もたらす。
上記モデル検証システムは、形式言語表現データとして、少なくとも、ＸＭＬ言語及び／又はＢＰＥＬ言語に対して、文法検査及び抽出検査に用いるＸＭＬスキーマ形式のデータまたは文章の一部を抽出するＸＰａｔｈ形式のデータを用いることが可能であり、加えて、ＲＯＩの数値化を｛ＲＯＩ値＝標準パターンのＫＰＩ／ＸＭＬインスタンスのＫＰＩ＊標準パターンの構成要素数／ＸＭＬインスタンスの構成要素数｝の数式を用いるので、既存のシステム全般に対して、設計モデルの検証が可能である。
加えて、モデル検証システムは、熟練者でも発生してしまう癖や偏りを排除し、既存システムのリファクタリングを、リソースの削減や処理時間の短縮などの多くのパラメータに対して、真に顧客の望む評価形態で行なえる。即ち、既存システムのプログラムを自動的に正当に評価して可能であれば置換や修正する仕組みと共に、派生設計を自動的に生成することで熟練者のサポートする仕組みとなる。
本発明によれば、電子データとして設計データが複数格納されているデータベースから、類似のものを探し出す用途や、ログデータを利用して類似の設計に優劣をつけ、設計の改善を行うといった用途に適用可能である。
この出願は、２００９年５月１２日に出願された日本出願特願２００９−１１５２７０号、および２００９年９月３日に出願された日本出願特願２００９−２０３２９５号を基礎とする優先権を主張し、その開示の全てをここに取り込む。
１００ 形式言語変換部（形式言語変換手段）
１１０ データ型判定部（データ型判定手段）
１２０ データパラメータ抽出部（データパラメータ抽出手段）
１３０ 形式言語生成部（形式言語生成手段）
２００ 形式言語増殖部（形式言語増殖手段）
２１０ 要素増殖部（要素増殖手段）
２２０ 要素置換部（要素置換手段）
２３０ 要素削減部（要素削減手段）
３００ 設計抽出部（データ型判定手段）
３１０ データ型判定部（データ型判定手段）
３２０ データパラメータ抽出部（データパラメータ抽出手段）
３３０ 情報表現生成部（情報表現生成手段）
３４０ 合致判定部（合致判定手段）
４００ 定量化部（定量化手段）
４１０ 合致ペア管理部（合致ペア管理手段）
４２０ ログ管理部（ログ管理手段）
４３０ ＫＰＩ算出部（ＫＰＩ算出手段）
５００ 選別部（選別手段）
５１０ 置き換え対象管理部（置き換え対象管理手段）
５２０ ＲＯＩ計算部（ＲＯＩ計算手段）
６００ 等価性検証部（等価性検証手段）
６１０ テストデータ抽出部（テストデータ抽出手段）
６２０ テスト実行部（テスト実行手段）
１０００ パターン蓄積部（パターン蓄積手段）
１１００ 既存システム設計蓄積部（既存システム設計蓄積手段）
１２００ 既存システム実行ログ蓄積部（既存システム実行ログ蓄積手段）
１３００ ＫＰＩ算出方式格納部（ＫＰＩ算出方式格納手段）
１４００ 既存システムテストデータ蓄積部（既存システムテストデータ蓄積手段）
１５００ 対応表蓄積部（対応表蓄積手段）
１１０ データ型判定部（データ型判定手段）
１２０ データパラメータ抽出部（データパラメータ抽出手段）
１３０ 形式言語生成部（形式言語生成手段）
２００ 形式言語増殖部（形式言語増殖手段）
２１０ 要素増殖部（要素増殖手段）
２２０ 要素置換部（要素置換手段）
２３０ 要素削減部（要素削減手段）
３００ 設計抽出部（データ型判定手段）
３１０ データ型判定部（データ型判定手段）
３２０ データパラメータ抽出部（データパラメータ抽出手段）
３３０ 情報表現生成部（情報表現生成手段）
３４０ 合致判定部（合致判定手段）
４００ 定量化部（定量化手段）
４１０ 合致ペア管理部（合致ペア管理手段）
４２０ ログ管理部（ログ管理手段）
４３０ ＫＰＩ算出部（ＫＰＩ算出手段）
５００ 選別部（選別手段）
５１０ 置き換え対象管理部（置き換え対象管理手段）
５２０ ＲＯＩ計算部（ＲＯＩ計算手段）
６００ 等価性検証部（等価性検証手段）
６１０ テストデータ抽出部（テストデータ抽出手段）
６２０ テスト実行部（テスト実行手段）
１０００ パターン蓄積部（パターン蓄積手段）
１１００ 既存システム設計蓄積部（既存システム設計蓄積手段）
１２００ 既存システム実行ログ蓄積部（既存システム実行ログ蓄積手段）
１３００ ＫＰＩ算出方式格納部（ＫＰＩ算出方式格納手段）
１４００ 既存システムテストデータ蓄積部（既存システムテストデータ蓄積手段）
１５００ 対応表蓄積部（対応表蓄積手段）
Claims (30)
- プログラムが対応付けられて設計パターンとして登録されているモデル図データを、所定の形式言語の表現形式に基づく形式言語表現データに変換する形式言語変換部と、
前記形式言語変換部によって変換した前記形式言語表現データに対して、前記形式言語での構成要素及び／又は属性情報に、修正を加えて派生設計の形式言語表現データを生成する形式言語増殖部と
を有することを特徴とするモデル検証システム。 - 前記形式言語変換部は、
前記モデル図データを拡張子及び／又はファイル先頭部に定義された型情報に基づいて、変換する形式言語の表現形式を判定するデータ型判定部と、
前記データ型判定部で判定した形式言語の特徴から、前記モデル図データから当該モデル図を特徴づけるパラメータを抽出するデータパラメータ抽出部と、
前記データパラメータ抽出部で抽出されたパラメータに基づき、形式言語表現データを生成する形式言語生成部と、
を含むことを特徴とする請求項１のモデル検証システム。 - 前記形式言語増殖部は、
前記形式言語表現データに対して、任意の構成要素及び／又は属性情報を示すデータを挿入して、派生設計の形式言語表現データを生成する要素増殖部、
前記形式言語表現データの一部を、任意の構成要素及び／又は属性情報を示すデータに置換して、派生設計の形式言語表現データを生成する要素置換部、
前記形式言語表現データの一部である任意の構成要素及び／又は属性情報を示すデータを削除して、派生設計の形式言語表現データを生成する要素削減部、
前記要素増殖部、前記要素置換部および前記要素削減部の出力結果を組み合わせて、派生設計の形式言語表現データを生成する統合部、
の何れか又は全てを備えることを特徴とする請求項１又は２に記載のモデル検証システム。 - 既存の設計済みデータであるモデル図データを、前記形式言語変換部で変換された形式言語表現データの表現形式に対応する情報表現形式の情報記述表現データに変換すると共に、前記形式言語表現データと前記情報記述表現データとの合致を判定する設計抽出部
を含むことを特徴とする請求項１ないし３の何れかに一記載のモデル検証システム。 - 設計抽出部として、
前記既存の設計済みデータであるモデル図データを拡張子及び／又はファイル先頭部に定義された型情報に基づいて、変換する情報記述表現形式を判定するデータ型判定部と、
前記データ型判定部で判定した情報記述表現形式の特徴から、前記モデル図データから当該モデル図を特徴づけるパラメータを抽出するデータパラメータ抽出部と、
前記データパラメータ抽出部で抽出されたパラメータに基づき、情報記述表現データを生成する情報表現生成部と、
前記形式言語表現データと、前記情報記述表現データが合致するか否か判定する合致判定部と、
を有することを特徴とする請求項１ないし３の何れかに一記載のモデル検証システム。 - 前記合致判定部での合致結果に基づき、ＫＰＩ推奨範囲値とＫＰＩ算出関数と既存設計ログデータを取得し、合致した前記情報記述表現データのＫＰＩ値を算出する定量化部、
を含むことを特徴とする請求項４又は５に記載のモデル検証システム。 - 定量化部として、
前記合致判定部で合致すると判定された判定結果に含まれるパターンＩＤとインスタンスＩＤを記憶する合致ペア管理部と、
前記合致ペア管理部で管理するインスタンスＩＤにマッチする既存設計ログデータを取得するログ管理部と、
前記合致ペア管理部で管理するパターンＩＤにマッチするＫＰＩ推奨範囲値とＫＰＩ算出関数を取得すると共に、前記ログ管理部で取得した既存設計ログデータを、ＫＰＩ推奨範囲値とＫＰＩ算出関数に適用して合致すると判定した前記情報記述表現データのＫＰＩ値を算出するＫＰＩ算出部
を有することを特徴とする請求項４又は５に記載のモデル検証システム。 - 前記定量化部によって得られた前記情報記述表現データのＫＰＩ値に基づき、置換候補と被置換候補を選別する選別部
を含むことを特徴とする請求項６又は７に記載のモデル検証システム。 - 選別部として、
前記定量化部によって定量化された複数の前記情報記述表現データから、同等のＫＰＩで比較可能であるＫＰＩ値を比較し、ＫＰＩ値の高い情報記述表現データを置換候補とし、それ以外の情報記述表現データを被置換候補として、候補間関係を記憶する置き換え対象管理部と、
前記置換候補と前記被置換候補とのＫＰＩ値の比率を求め、置換した場合のＲＯＩ値を算出するＲＯＩ計算部と
を有することを特徴とする請求項６又は７に記載のモデル検証システム。 - テストデータを用いて、前記選別部による前記置換候補と前記被置換候補との選別結果の動作検証を行なう等価性検証部
を含むことを特徴とする請求項８又は９に記載のモデル検証システム。 - 等価性検証部として、
前記被置換候補うち、パターンにマッチする部分のみを利用するテストケースを抽出すると共に、テストケースを実行するために必要な入力データと、実行後に期待される結果を示す検証データを取得するテストデータ抽出部と、
前記被置換候補それぞれについて入手したテスト用入力データと検証データを、前記置換候補のテストケースに適用して置換可能であることを動作検証するテスト実行部と
を有することを特徴とする請求項８又は９に記載のモデル検証システム。 - 前記形式言語表現データは、ＸＭＬ言語及び／又はＢＰＥＬ言語に対して、文法検査及び抽出検査に用いるＸＭＬスキーマ形式のデータであることを特徴とする請求項１ないし１１の何れか一記載のモデル検証システム。
- 前記形式言語表現データは、ＸＭＬ言語及び／又はＢＰＥＬ言語に対して、文法検査及び抽出検査に用いるＸＰａｔｈ形式のデータであることを特徴とする請求項１ないし１１の何れか一記載のモデル検証システム。
- 人間の目視用に作成されたコンピュータプログラムの設計を示すＵＭＬパターン図データを、ＸＭＬスキーマ言語形式又はＸＰａｔｈ形式の形式言語表現データに変換する形式言語変換部と、
前記形式言語変換部で変換した前記形式言語表現データに対して、要素及び属性の情報を追加、変更、削除の何れか又はその組合せを実施して、前記形式言語表現データに類似する仮想的な派生設計の形式言語表現データを生成する形式言語増殖部と、
前記形式言語変換部で生成された前記形式言語表現データおよび前記形式言語増殖部で生成した派生設計の形式言語表現データと、既存システムの設計として予め蓄積されているＵＭＬパターン図データを変換した前記ＸＭＬスキーマ言語形式または前記ＸＰａｔｈ形式に対応する情報表現形式の情報記述表現データとの合致を判定し、合致した情報記述表現データを抽出する設計抽出部と、
前記設計抽出部で抽出された情報記述表現データに対して、既存システムの実行ログを用いて、ＫＰＩ値を算出して定量化する定量化部と、
前記定量化部で算出したＫＰＩ値に基づき、前記抽出された情報記述表現データと関連する前記形式言語表現データとのＫＰＩ値を比較し、良い値のデータをリンク先とし、それ以外のデータをリンク元とする関連づけを実施すると共に、既存システムの設計に対して、前記関連づけを実施したデータ間の設計の置換によるＲＯＩを算出して、置換の効果的な設計を選別する選別部と
を有することを特徴とするモデル検証システム。 - プログラムが対応付けられて設計パターンとして登録されているモデル図データを、所定の形式言語の表現形式に基づく形式言語表現データに変換し、
変換した前記形式言語表現データに対して、前記形式言語での構成要素及び／又は属性情報に、修正を加えて派生設計の形式言語表現データを生成し、
生成した情報を用いてモデル図データを検証することを特徴とするモデル検証方法。 - 形式言語表現データへの変換は、
前記モデル図データを拡張子及び／又はファイル先頭部に定義された型情報に基づいて、変換する形式言語の表現形式を判定し、
判定した形式言語の特徴から、前記モデル図データから当該モデル図を特徴づけるパラメータを抽出し、
抽出されたパラメータに基づき、形式言語表現データを生成し、
生成した情報を用いてモデル図データを検証することを特徴とする請求項１５のモデル検証方法。 - 派生設計の形式言語表現データを生成は、
前記形式言語表現データに対して、任意の構成要素及び／又は属性情報を示すデータを挿入して、派生設計の形式言語表現データを生成し、
又は、前記形式言語表現データの一部を、任意の構成要素及び／又は属性情報を示すデータに置換して、派生設計の形式言語表現データを生成し、
又は、前記形式言語表現データの一部である任意の構成要素及び／又は属性情報を示すデータを削除して、派生設計の形式言語表現データを生成し、
又は、前記生成した結果を組み合わせて、派生設計の形式言語表現データを生成し、
生成した情報を用いてモデル図データを検証することを特徴とする請求項１５又は１６に記載のモデル検証方法。 - 既存の設計済みデータであるモデル図データを、変換した形式言語表現データの表現形式に対応する情報表現形式の情報記述表現データに変換すると共に、前記形式言語表現データと前記情報記述表現データとの合致を判定する情報を生成し、
生成した情報を用いてモデル図データを検証することを特徴とする請求項１５ないし１７の何れかに一記載のモデル検証方法。 - 前記合致結果に基づき、ＫＰＩ推奨範囲値とＫＰＩ算出関数と既存設計ログデータを取得し、
合致した前記情報記述表現データのＫＰＩ値を算出し、
算出した情報を用いてモデル図データを検証することを特徴とする請求項１８記載のモデル検証方法。 - 前記情報記述表現データのＫＰＩ値に基づき、置換候補と被置換候補を選別する情報を生成し、
生成した情報を用いてモデル図データを検証することを特徴とする請求項１９記載のモデル検証方法。 - テストデータを用いて、前記置換候補と前記被置換候補との動作検証を実施し、
モデル図データを検証することを特徴とする請求項２０記載のモデル検証方法。 - 前記形式言語表現データとして、ＸＭＬ言語及び／又はＢＰＥＬ言語に対して、文法検査及び抽出検査に用いるＸＭＬスキーマ形式またはＸＰａｔｈ形式のデータを用いて、モデル図データを検証することを特徴とする請求項１５ないし２１の何れか一記載のモデル検証方法。
- 情報処理装置の制御部を、
プログラムが対応付けられて設計パターンとして登録されているモデル図データを、所定の形式言語の表現形式に基づく形式言語表現データに変換する形式言語変換部と、
前記形式言語変換部によって変換した前記形式言語表現データに対して、前記形式言語での構成要素及び／又は属性情報に、修正を加えて派生設計の形式言語表現データを生成する形式言語増殖部と
して機能させることを特徴とするモデル検証プログラムを記録した記録媒体。 - 前記形式言語変換部を、
前記モデル図データを拡張子及び／又はファイル先頭部に定義された型情報に基づいて、変換する形式言語の表現形式を判定するデータ型判定部と、
前記データ型判定部で判定した形式言語の特徴から、前記モデル図データから当該モデル図を特徴づけるパラメータを抽出するデータパラメータ抽出部と、
前記データパラメータ抽出部で抽出されたパラメータに基づき、形式言語表現データを生成する形式言語生成部と、
して機能させることを特徴とする請求項２３記載のモデル検証プログラムを記録した記録媒体。 - 形式言語増殖部を、
前記形式言語表現データに対して、任意の構成要素及び／又は属性情報を示すデータを挿入して、派生設計の形式言語表現データを生成する要素増殖部、
前記形式言語表現データの一部を、任意の構成要素及び／又は属性情報を示すデータに置換して、派生設計の形式言語表現データを生成する要素置換部、
前記形式言語表現データの一部である任意の構成要素及び／又は属性情報を示すデータを削除して、派生設計の形式言語表現データを生成する要素削減部、
前記要素増殖部、前記要素置換部および前記要素削減部の出力結果を組み合わせて、派生設計の形式言語表現データを生成する統合部
の何れか又は全てをとして機能させることを特徴とする請求項２３又は２４に記載のモデル検証プログラムを記録した記録媒体。 - 前記制御部を、
既存の設計済みデータであるモデル図データを、前記形式言語変換部で変換された形式言語表現データの表現形式に対応する情報表現形式の情報記述表現データに変換すると共に、前記形式言語表現データと前記情報記述表現データとの合致を判定する設計抽出部
として更に機能させることを特徴とする請求項２３ないし２５の何れかに一記載のモデル検証プログラムを記録した記録媒体。 - 前記制御部を、
前記合致判定部での合致結果に基づき、ＫＰＩ推奨範囲値とＫＰＩ算出関数と既存設計ログデータを取得し、合致した前記情報記述表現データのＫＰＩ値を算出する定量化部、
として更に機能させることを特徴とする請求項２５記載のモデル検証プログラムを記録した記録媒体。 - 前記制御部を、
前記定量化部によって得られた前記情報記述表現データのＫＰＩ値に基づき、置換候補と被置換候補を選別する選別部と、
テストデータを用いて、前記選別部による前記置換候補と前記被置換候補との選別結果の動作検証を行なう等価性検証部
として機能させることを特徴とする請求項２６記載のモデル検証プログラムを記録した記録媒体。 - 前記形式言語表現データとして、ＸＭＬ言語及び／又はＢＰＥＬ言語に対して、文法検査及び抽出検査に用いるＸＭＬスキーマ形式またはＸＰａｔｈ形式のデータを用いることを特徴とする請求項２３ないし２８の何れか一記載のモデル検証プログラムを記録した記録媒体。
- 前記モデル図データの検証の定量化に用いる値の算出を、
｛ＲＯＩ値＝標準パターンのＫＰＩ／ＸＭＬインスタンスのＫＰＩ＊標準パターンの構成要素数／ＸＭＬインスタンスの構成要素数｝
の数式を用いる
ことを特徴とする請求項２３ないし２９の何れか一記載のモデル検証プログラムを記録した記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2011513396A JP5207007B2 (ja) | 2009-05-12 | 2010-05-10 | モデル検証システム、モデル検証方法および記録媒体 |
Applications Claiming Priority (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2009115270 | 2009-05-12 | ||
| JP2009115270 | 2009-05-12 | ||
| JP2009203295 | 2009-09-03 | ||
| JP2009203295 | 2009-09-03 | ||
| JP2011513396A JP5207007B2 (ja) | 2009-05-12 | 2010-05-10 | モデル検証システム、モデル検証方法および記録媒体 |
| PCT/JP2010/058244 WO2010131758A1 (ja) | 2009-05-12 | 2010-05-10 | モデル検証システム、モデル検証方法および記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPWO2010131758A1 JPWO2010131758A1 (ja) | 2012-11-08 |
| JP5207007B2 true JP5207007B2 (ja) | 2013-06-12 |
Family
ID=43085130
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2011513396A Expired - Fee Related JP5207007B2 (ja) | 2009-05-12 | 2010-05-10 | モデル検証システム、モデル検証方法および記録媒体 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US9170918B2 (ja) |
| JP (1) | JP5207007B2 (ja) |
| WO (1) | WO2010131758A1 (ja) |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8949773B2 (en) * | 2010-03-25 | 2015-02-03 | International Business Machines Corporation | Deriving process models from natural language use case models |
| US8893087B2 (en) * | 2011-08-08 | 2014-11-18 | Ca, Inc. | Automating functionality test cases |
| WO2013180453A1 (ko) * | 2012-05-29 | 2013-12-05 | 주성엔지니어링(주) | 기판 처리 장치 및 기판 처리 방법 |
| US9027001B2 (en) * | 2012-07-10 | 2015-05-05 | Honeywell International Inc. | Systems and methods for verifying expression folding |
| JP6142878B2 (ja) * | 2012-10-02 | 2017-06-07 | 日本電気株式会社 | 情報システムの性能評価装置、方法およびプログラム |
| JP6095431B2 (ja) * | 2013-03-21 | 2017-03-15 | 日本無線株式会社 | 無線機ソフトウェアモデルジェネレータおよび無線通信装置 |
| JP6052801B2 (ja) * | 2013-07-31 | 2016-12-27 | インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ | 文書間における記載事項関連付けシステム、方法、及び、プログラム |
| CN106537333A (zh) * | 2014-06-13 | 2017-03-22 | 查尔斯斯塔克德拉珀实验室公司 | 用于软件产物的数据库的系统和方法 |
| CN104504221A (zh) * | 2015-01-13 | 2015-04-08 | 北京恒华伟业科技股份有限公司 | 一种评审数据处理方法和系统 |
| CN105184513A (zh) * | 2015-10-16 | 2015-12-23 | 北京恒华伟业科技股份有限公司 | 一种评审结果的输出方法及系统 |
| CN106570668A (zh) * | 2016-11-02 | 2017-04-19 | 深圳效率科技有限公司 | 一种物料清单的信息整理方法及装置 |
| WO2018163304A1 (ja) * | 2017-03-07 | 2018-09-13 | 三菱電機株式会社 | ソースコード改善装置、ソースコード改善方法及びソースコード改善プログラム |
| WO2020184597A1 (ja) * | 2019-03-14 | 2020-09-17 | 日本電気株式会社 | ルール統合装置、ルール統合方法及びプログラムを記憶する記憶媒体 |
| US11222037B2 (en) * | 2019-06-26 | 2022-01-11 | Sap Se | Intelligent message mapping |
| JP7508841B2 (ja) * | 2020-04-07 | 2024-07-02 | 日本電気株式会社 | システム検証プログラム生成装置、システム検証プログラム生成方法およびシステム検証プログラム生成プログラム |
| US11551177B2 (en) * | 2020-06-29 | 2023-01-10 | Tata Consultancy Services Limited | Method and system for handling source field and key performance indicator calculation changes |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000231489A (ja) * | 1999-02-10 | 2000-08-22 | Oki Electric Ind Co Ltd | オブジェクト設計支援装置および方法 |
| JP2001109649A (ja) * | 1999-10-12 | 2001-04-20 | Nec Corp | コンピュータシステムにおけるｃｐｕリソース改善の評価装置およびその評価方法 |
| JP2004220453A (ja) * | 2003-01-17 | 2004-08-05 | Nec Corp | ソフトウェア・コンポーネントの性能測定を基にしたシステム性能予測方式および方法 |
| JP2008243019A (ja) * | 2007-03-28 | 2008-10-09 | Toshiba Corp | ソースコード変換装置及びソースコード変換方法 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003337697A (ja) | 2002-05-20 | 2003-11-28 | Ul Systems Inc | ビジネスシステムの開発システムおよびビジネスシステムの開発方法 |
| JP2005174120A (ja) | 2003-12-12 | 2005-06-30 | Toshiba Corp | Ｗｅｂサービス接続処理方法とシステム、およびプログラム |
| EP1730629A4 (en) * | 2004-03-02 | 2010-06-23 | Metaphor Vision Ltd | DEVICE, SYSTEM AND METHOD FOR ACCELERATED MODELING |
| WO2006043012A1 (en) * | 2004-10-22 | 2006-04-27 | New Technology/Enterprise Limited | Data processing system and method |
| US7716573B2 (en) * | 2005-09-28 | 2010-05-11 | International Business Machines Corporation | Method and system for broadly sharing UML-based models |
| JP2007179171A (ja) * | 2005-12-27 | 2007-07-12 | Internatl Business Mach Corp <Ibm> | 秘密保持が要求されるモデル用のソフトウエア開発装置 |
| US20100114618A1 (en) * | 2008-10-30 | 2010-05-06 | Hewlett-Packard Development Company, L.P. | Management of Variants of Model of Service |
-
2010
- 2010-05-10 WO PCT/JP2010/058244 patent/WO2010131758A1/ja active Application Filing
- 2010-05-10 US US13/260,305 patent/US9170918B2/en not_active Expired - Fee Related
- 2010-05-10 JP JP2011513396A patent/JP5207007B2/ja not_active Expired - Fee Related
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000231489A (ja) * | 1999-02-10 | 2000-08-22 | Oki Electric Ind Co Ltd | オブジェクト設計支援装置および方法 |
| JP2001109649A (ja) * | 1999-10-12 | 2001-04-20 | Nec Corp | コンピュータシステムにおけるｃｐｕリソース改善の評価装置およびその評価方法 |
| JP2004220453A (ja) * | 2003-01-17 | 2004-08-05 | Nec Corp | ソフトウェア・コンポーネントの性能測定を基にしたシステム性能予測方式および方法 |
| JP2008243019A (ja) * | 2007-03-28 | 2008-10-09 | Toshiba Corp | ソースコード変換装置及びソースコード変換方法 |
Non-Patent Citations (4)
| Title |
|---|
| CSNG200500878005; 丸山勝久: 'ＸＭＬを用いた拡張性の高いリファクタリングツール' 電子情報通信学会論文誌 Ｖｏｌ．Ｊ８８-Ｄ-Ｉ，Ｎｏ．２, 20050201, ｐｐ．１７５〜１８５, 社団法人電子情報通信学会 * |
| CSNJ200810058115; 本間昭次、片岡欣夫、深谷哲司: 'リファクタリングによるソフトウェア品質改善と品質劣化の予防 （２）リファクタリング支援ツールＲｅｆａｃｔｏｒｉｎｇ' 第６３回（平成１３年後期）全国大会講演論文集（１） , 20010926, ｐｐ．１-２３１〜１-２３２， （４Ｒ-５）, 社団法人情報処理学会 * |
| JPN6013002607; 丸山勝久: 'ＸＭＬを用いた拡張性の高いリファクタリングツール' 電子情報通信学会論文誌 Ｖｏｌ．Ｊ８８-Ｄ-Ｉ，Ｎｏ．２, 20050201, ｐｐ．１７５〜１８５, 社団法人電子情報通信学会 * |
| JPN6013002608; 本間昭次、片岡欣夫、深谷哲司: 'リファクタリングによるソフトウェア品質改善と品質劣化の予防 （２）リファクタリング支援ツールＲｅｆａｃｔｏｒｉｎｇ' 第６３回（平成１３年後期）全国大会講演論文集（１） , 20010926, ｐｐ．１-２３１〜１-２３２， （４Ｒ-５）, 社団法人情報処理学会 * |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2010131758A1 (ja) | 2010-11-18 |
| US20120011487A1 (en) | 2012-01-12 |
| JPWO2010131758A1 (ja) | 2012-11-08 |
| US9170918B2 (en) | 2015-10-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5207007B2 (ja) | モデル検証システム、モデル検証方法および記録媒体 | |
| Raharjana et al. | User stories and natural language processing: A systematic literature review | |
| Rozinat et al. | Conformance testing: Measuring the fit and appropriateness of event logs and process models | |
| US8819642B2 (en) | Method and system for generating and processing black box test cases | |
| Rozinat | Process mining: conformance and extension | |
| Mohagheghi et al. | An empirical investigation of software reuse benefits in a large telecom product | |
| US8621417B2 (en) | Rule merging in system for monitoring adherence by developers to a software code development process | |
| Martin-Lopez et al. | Specification and automated analysis of inter-parameter dependencies in web APIs | |
| Martínez-Ruiz et al. | Requirements and constructors for tailoring software processes: a systematic literature review | |
| US20100114628A1 (en) | Validating Compliance in Enterprise Operations Based on Provenance Data | |
| US20100325491A1 (en) | Mining a use case model by analyzing its description in plain language and analyzing textural use case models to identify modeling errors | |
| Hojaji et al. | Model execution tracing: a systematic mapping study | |
| US8145992B2 (en) | Validation assisted document conversion design | |
| Popoola et al. | EMG: A domain-specific transformation language for synthetic model generation | |
| Runge et al. | Test case generation using visual contracts | |
| CN115374595A (zh) | 一种基于过程挖掘的自动化软件过程建模方法及系统 | |
| Malik et al. | Automating test oracles from restricted natural language agile requirements | |
| Bass et al. | A comparison of requirements specification methods from a software architecture perspective | |
| JP4954674B2 (ja) | ソフトウェア開発支援方法、ソフトウェア開発支援装置、ソフトウェア開発支援プログラム、及び計算機システム | |
| Tatale et al. | A Survey on Test Case Generation using UML Diagrams and Feasibility Study to Generate Combinatorial Logic Oriented Test Cases. | |
| Tawhid et al. | User-friendly approach for handling performance parameters during predictive software performance engineering | |
| Ilahi et al. | BPFlexTemplate: A Business Process template generation tool based on similarity and flexibility | |
| US8645908B2 (en) | Method for generating specifications of static test | |
| JP3703076B2 (ja) | 構造化文書により定義された品質管理及び品質評価ルールによるソフトウェア品質管理・評価方法、ならびにそのプログラムを記録した記録媒体 | |
| Brüseke et al. | PBlaman: performance blame analysis based on Palladio contracts |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20130123 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20130205 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20160301 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 5207007 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |