特許 6011712 修正管理装置、修正管理方法、及び修正管理プログラム

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

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

(11)【特許番号】6011712

(24)【登録日】2016年9月30日

(45)【発行日】2016年10月19日

(54)【発明の名称】修正管理装置、修正管理方法、及び修正管理プログラム

(51)【国際特許分類】

   G06F 9/44 20060101AFI20161006BHJP

【ＦＩ】

   G06F9/06 620K

【請求項の数】11

【全頁数】16

(21)【出願番号】特願2015-501985(P2015-501985)

(86)(22)【出願日】2012年7月31日

(65)【公表番号】特表2015-527621(P2015-527621A)

(43)【公表日】2015年9月17日

(86)【国際出願番号】JP2012069937

(87)【国際公開番号】WO2014020773

(87)【国際公開日】20140206

【審査請求日】2015年6月17日

(73)【特許権者】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100109313

【弁理士】

【氏名又は名称】机 昌彦

(74)【代理人】

【識別番号】100124154

【弁理士】

【氏名又は名称】下坂 直樹

(72)【発明者】

【氏名】サタウォンウィチット チャイワット

(72)【発明者】

【氏名】細野 繁

【審査官】 石川 亮

(56)【参考文献】

【文献】 特開２０００−１４８４６１（ＪＰ，Ａ）

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

Ｇ０６Ｆ ９／４４

Ｇ０６Ｆ １１／３６

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

【請求項1】

モデリング言語内にオブジェクトの構造を記載する設計モデルを記憶する設計モデル記憶手段と、
プログラミング言語内の前記オブジェクトを記載するアプリケーションプログラムを記憶するプログラム記憶手段と、
前記オブジェクトの前記構造を記載するメタデータを記憶するメタデータ記憶手段と、
前記アプリケーションプログラム及び前記設計モデルのうちの一方になされた修正から前記構造内の変更を抽出し、前記構造内の前記変更に従って前記メタデータを更新し、前記更新されたメタデータに従って前記アプリケーションプログラム及び前記設計モデルのうちの他方に対して前記構造内の前記変更を反映する操作手段と、
前記アプリケーションプログラムをテストするためのテスト部品を記憶するテスト部品記憶手段を備え、
前記操作手段は、前記アプリケーションプログラム、前記設計モデル、及び前記テスト部品のうちの１つにおいてなされた修正から前記構造内の前記変更を抽出し、前記アプリケーションプログラム、前記設計モデル、及び前記テスト部品のうちの他の２つに対して、前記構造内の前記変更を反映する
修正管理装置。

【請求項2】

前記オブジェクトの前記構造は、属性の名前及びタイプ、メソッド及び前記メソッドの引数を含み、前記操作手段によって抽出されて反映された前記構造内の前記変更は、前記名前及び／又は前記タイプ内の変更を含む
請求項１に記載の修正管理装置。

【請求項3】

前記オブジェクトの前記構造は、メソッドの属性及び名前を含み、前記操作手段によって抽出されて反映された前記構造内の前記変更は、新たな属性の及び／又は新たなメソッドの追加、及び／又は、既存の属性及び／又は既存のメソッドの除去を含む
請求項１に記載の修正管理装置。

【請求項4】

前記操作手段は、１）前記設計モデル及び前記アプリケーションプログラムから第１のメタデータ及び第２のメタデータをそれぞれ生成して、前記メタデータ記憶手段に格納し、２ａ）前記第１のメタデータを参照して、前記設計モデル内でなされた修正から前記構造内の前記変更を抽出し、前記第１のメタデータ及び前記第２のメタデータに対して前記変更を反映し、その後、前記第２のメタデータを参照して、前記アプリケーションプログラムに対して前記構造内の前記変更を反映し、又は２ｂ）前記第２のメタデータを参照して、前記アプリケーションプログラム内でなされた修正から前記構造内の前記変更を抽出し、前記第１のメタデータ及び第２のメタデータに対して前記変更を反映し、その後、前記第１のメタデータを参照して、前記設計モデルに対して前記構造内の前記変更を反映する
請求項１乃至３のいずれか１項に記載の修正管理装置。

【請求項5】

前記操作手段が前記変更を反映し終えた後に前記テスト部品を用いて前記アプリケーションプログラムをテストするテスト制御手段
を更に備える請求項４に記載の修正管理装置。

【請求項6】

プログラミング言語内のオブジェクトを記載するアプリケーションプログラム及びモデリング言語内に前記オブジェクトの構造を記載する設計モデルのうちの一方になされた修正から前記構造内の変更を抽出し、前記構造内の前記変更に従って前記オブジェクトの前記構造を記載するメタデータを更新し、前記更新されたメタデータに従って前記アプリケーションプログラム及び前記設計モデルのうちの他方に対して前記構造内の前記変更を反映し、
前記反映の際に、前記アプリケーションプログラム、前記設計モデル、及び前記アプリケーションプログラムをテストするためのテスト部品のうちの１つにおいてなされた修正から前記構造内の前記変更を抽出し、前記アプリケーションプログラム、前記設計モデル、及び前記テスト部品のうちの他の２つに対して、前記構造内の前記変更を反映する
修正管理方法。

【請求項7】

前記オブジェクトの前記構造は、属性の名前及びタイプ、メソッド及び前記メソッドの引数を含み、抽出され反映された前記構造内の前記変更は、前記名前及び／又は前記タイプ内の変更を含む
請求項６に記載の修正管理方法。

【請求項8】

前記オブジェクトの前記構造は、メソッドの属性及び名前を含み、抽出され反映された前記構造内の前記変更は、新たな属性の及び／又は新たなメソッドの追加、及び／又は、既存の属性及び／又は既存のメソッドの除去を含む
請求項６に記載の修正管理方法。

【請求項9】

プログラミング言語内のオブジェクトを記載するアプリケーションプログラム及びモデリング言語内に前記オブジェクトの構造を記載する設計モデルのうちの一方になされた修正から前記構造内の変更を抽出し、前記構造内の前記変更に従って前記オブジェクトの前記構造を記載するメタデータを更新し、前記更新されたメタデータに従って前記アプリケーションプログラム及び前記設計モデルのうちの他方に対して前記構造内の前記変更を反映し、
前記反映の際に、前記アプリケーションプログラム、前記設計モデル、及び前記アプリケーションプログラムをテストするためのテスト部品のうちの１つにおいてなされた修正から前記構造内の前記変更を抽出し、前記アプリケーションプログラム、前記設計モデル、及び前記テスト部品のうちの他の２つに対して、前記構造内の前記変更を反映する
処理をコンピュータに実行させる修正管理プログラム。

【請求項10】

前記オブジェクトの前記構造は、属性の名前及びタイプ、メソッド及び前記メソッドの引数を含み、抽出され反映された前記構造内の前記変更は、前記名前及び／又は前記タイプ内の変更を含む
請求項９に記載の修正管理プログラム。

【請求項11】

前記オブジェクトの前記構造は、メソッドの属性及び名前を含み、抽出され反映された前記構造内の前記変更は、新たな属性の及び／又は新たなメソッドの追加、及び／又は、既存の属性及び／又は既存のメソッドの除去を含む
請求項９に記載の修正管理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、概して、修正管理装置、修正管理方法、及び修正管理プログラムに関する。より具体的には、本発明は、ソフトウェアの更新、及び設計とプログラムとの間の整合性の維持に関する。

【背景技術】

【0002】

ソフトウェア開発において、特にアジャイルソフトウェア開発において、要件又は仕様の変更がしばしば生じる場合がある。変更が生ずると、機能仕様書、設計書、実装、テスト仕様書、及びテストプログラムの間の整合性を維持する必要がある。

【0003】

通常、設計書、実装、テスト仕様書、及びプログラムの間の整合性は、手動によって維持される。結果として、変更が生じる度に、設計書とプログラム内のコードとを更新し、更新プログラムを再コンパイルして再実行する必要がある。そのため、変更する度に、更なるコストが加わり、開発サイクルのペースが落ちる。この問題は、ソフトウェア開発にとって障害になる。

【0004】

技術の進歩は、コンピューティングシステムのソフトウェアの整合性をある程度まで維持しながら、更新のためのコストの低減を可能にしている。特許文献１には、入力された設計定義から、テスト仕様書及びテストコードを生成するためのシステムが開示される。特許文献２には、別の関連システムが開示される。これらのシステムは、相対的に少ないコードにより、オブジェクトの属性のための値を一括して一度に設定することを目的とする。特許文献３は、ａ）データ型、データ名などを含む定義、及び、ｂ）標準シナリオ又は標準スクリプトからスクリプトを生成するシステムを開示する。特許文献４は、プログラム設計管理システムを開示する。このシステムにおいて、メタデータは、ファイルの構成情報を含み、設計過程の間に設計者によって修正される。システムは、それに対応するファイルに対してメタデータ内の変更を反映する。他の関連システムは、特許文献５〜８に開示される。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２００７−０６６２０４号公報

【特許文献2】特開２００４−２５２７０８号公報

【特許文献3】特開２００２−３６６３８７号公報

【特許文献4】特開２００６−７９２１２号公報

【特許文献5】特開２００４−２２０３３０号公報

【特許文献6】特開２００６−０９９７４３号公報

【特許文献7】特開２００７−０１１４６７号公報

【特許文献8】特開２０１１−１２８９４０号公報

【発明の概要】

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

【0006】

システムの要件又は仕様に変更が生じると、その設計書及び実装に対して変更が適切に反映されるか確かめる必要がある。更に、テストに関わるものであると、仕様書、設計書、実装、テスト仕様書、及びテストプログラムの間の整合性を維持する必要がある。

【0007】

問題は、設計書、実装、テスト仕様書、及びテストプログラムの間の整合性の維持が、恐らく別人である、設計者、開発者、及び試験者の手動によって非能率的に行われるということである。設計書及び実装の１つに対していくつかの変更がなされると、特許文献１〜８に開示された技術では、整合性を維持できない。

【0008】

本発明の目的は、上記の問題を解決する修正管理装置、修正管理方法、及び修正管理プログラムを提供することである。

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

【0009】

本発明によると、上述の課題は、
モデリング言語内にオブジェクトの構造を記載する設計モデルを記憶する設計モデル記憶手段と、
プログラミング言語内のオブジェクトを記載するアプリケーションプログラムを記憶するプログラム記憶手段と、
オブジェクトの構造を記載するメタデータを記憶するメタデータ記憶手段と、
アプリケーションプログラム及び設計モデルのうちの一方になされた修正から構造内の変更を抽出し、構造内の変更に従ってメタデータを更新し、更新されたメタデータに従ってアプリケーションプログラム及び設計モデルのうちの他方に対して構造内の変更を反映する操作手段と
を備える修正管理装置により解決される。

【0010】

本発明によると、上述の課題は、
モデリング言語内にオブジェクトの構造を記載する設計モデルを記憶し、
プログラミング言語内のオブジェクトを記載するアプリケーションプログラムを記憶し、
オブジェクトの構造を記載するメタデータを記憶し、
アプリケーションプログラム及び設計モデルのうちの一方になされた修正から構造内の変更を抽出し、構造内の変更に従ってメタデータを更新し、更新されたメタデータに従ってアプリケーションプログラム及び設計モデルのうちの他方に対して構造内の変更を反映すること
を備える修正管理方法により解決される。

【0011】

本発明によると、上述の課題は、
モデリング言語内にオブジェクトの構造を記載する設計モデルを記憶し、
プログラミング言語内のオブジェクトを記載するアプリケーションプログラムを記憶し、
オブジェクトの構造を記載するメタデータを記憶し、
アプリケーションプログラム及び設計モデルのうちの一方になされた修正から構造内の変更を抽出し、構造内の変更に従ってメタデータを更新し、更新されたメタデータに従ってアプリケーションプログラム及び設計モデルのうちの他方に対して構造内の変更を反映する処理
をコンピュータに実行させる修正管理プログラムにより解決される。

【発明の効果】

【0012】

本発明は、設計書と実装との間の整合性を維持するためのコスト及び負担が軽減される効果を有する。

【図面の簡単な説明】

【0013】

【図1】修正管理装置を図示する簡略ブロック図である。

【図2】テスト制御／実行モジュールを図示する簡略ブロック図である。

【図3】テスト部品を図示する簡略ブロック図である。

【図4】メタデータレコードを表す図である。

【図5】メタデータ操作モジュール、及びそれを維持するメタデータを図示する簡略ブロック図である。

【図6】ＵＭＬクラス図内に示される口座クラス（class Account）の設計モデルを表す図である。

【図7】テストシステムの動作の流れを示す図である。

【図8】いくつかの変更がソースコードにおいて生じた場合のメタデータ操作モジュールの動作の流れを示す図である。

【図9】第２の実施形態における修正管理装置を図示する簡略ブロック図である。

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

【0014】

本発明が様々な変形及び代替形態の余地のある一方で、その特定の実施形態は、図面内の例として示されており、詳細な説明によって本明細書において記載されることになる。但し、本発明を開示された特定の形態に限定するようには意図しておらず、逆に、本発明が、添付の請求項によって定義されるような本発明の精神及び範囲以内にある変形、均等物、及び代替手段をすべて網羅することを理解するべきである。

【0015】

図１を参照すると、テストシステム１００の簡略ブロック図が表される。図１のテストシステム１００は、本発明の修正管理装置３００の例である。テストシステム１００は、設計モデル入力モジュール１０２及びテスト結果報告モジュール１１２に接続される。設計モデル入力モジュール１０２は、端末装置であってもよい。テスト結果報告モジュール１１２は、ディスプレイ装置であってもよい。

【0016】

テストシステム１００は、メタデータ操作モジュール１０６と、テスト制御／実行モジュール１１０と、設計モデル記憶部２００と、プログラム記憶部２０１と、テスト部品記憶部２０２と、メタデータ記憶部２０３とを含む。

【0017】

メタデータ操作モジュール１０６及びテスト制御／実行モジュール１１０は、コンピュータであるテストシステム１００のプロセッサがメモリ内に格納されたプログラムを読み込んで実行すると機能する。同等の機能は、集積回路などのハードウェア部によって実現されることができる。設計モデル記憶部２００、プログラム記憶部２０１、テスト部品記憶部２０２及びメタデータ記憶部２０３は、ハードウェアディスクドライブ又はＩＣメモリのようなメモリ装置であってもよい。

【0018】

また、図１に示すのは、テスト対象システム（ＳＵＴ）１１４の構成要素である。テスト対象システム１１４は、テストシステム１００と、設計モデル１２０と、テスト部品１１６とによってテストされる対象である。設計モデル１２０は、テスト対象システムの構造的側面及び行動的側面を表現する。テスト部品１１６は、テスト対象システム１１４と通信する部品又はテストの行動的側面を実現する外部構成要素である設計モデル１２０、テスト対象システム１１４、及びテスト部品１１６は、設計モデル記憶部２００、プログラム記憶装置２０１及びテスト部品記憶装置２０２内にそれぞれ格納される。

【0019】

例えば、テスト対象システム１１４は、アプリケーションプログラムのようなソフトウェアであってもよい。テスト対象システム１１４は、Ｃ＋＋又はＪＡＶＡ（登録商標）言語のようなオブジェクト指向言語を用いてアプリケーションシステム内のオブジェクトの構造及び行動を記載し、グラフィカルユーザインタフェースによりパーソナルコンピュータ上で動作する。テスト対象システム１１４の別の例は、ネットワーク又は通信チャネルによって接続される１つ以上のコンピュータ上で実行するクライアント・サーバプログラムである。テスト対象システム１１４の更なる例は、携帯電話又はタブレット型コンピュータなどのモバイル機器のマイクロプロセッサ上に動作する制御プログラムである。本発明を実施するための装置、システム、及び方法は、あらゆるタイプのテスト対象システム１１４により同様に充分に機能し、本明細書における例示的な実施形態は、請求項に係る発明を何らかの方法で限定するようには意図されない。

【0020】

図３内に示されるテスト部品１１６は、テストシーケンス及びテストの動作条件を定義する。また、テスト部品１１６は、１つ以上のソフトウェアモジュールから構成されてもよい。その１つ以上のソフトウェアモジュールは、テスト対象システム１１４が動作する条件を初期化し、テスト対象システム１１４の適切な行動を確認するために行われる動作のシーケンスを定義し、及び／又は、テスト対象システム１１４への入力を提供することによって、テスト対象システム１１４と相互に作用することができる。例えば、ＡＴＭ（現金自動預け払い機）を用いて、銀行口座から現金を引き出すシナリオの適切な行動を確認するために、テスト部品１１６は、ソフトウェアモジュールから構成されてもよい。そのソフトウェアモジュールは、引き出す口座、認証のためのＰＩＮコード及びカードデータベース、バンキングシステムによって行われる引き出し動作のシーケンス、及びＡＴＭに対する預金引き出しの入力を設定する。

【0021】

テスト部品１１６は、ソースコードを編集することができるテキストエディタ内にプログラムコードを入力することによって、手動的に生成されてもよい。又は、テスト部品１１６は、プロトタイプから部分的に自動的に生成され、その後、テキストエディタによって要求通り修正されてもよい。例えば、テスト部品１１６は、動作条件がシナリオからシナリオに変化するように、テスト対象システム１１４のための複数の動作条件を設定するために修正されてもよい。

【0022】

設計モデル１２０は、テスト対象システム１１４の構造的側面及び／又は行動的側面を表現することができるモデリング言語により記載されてもよい。設計モデル１２０は、テスト対象システム１１４内のオブジェクトの構造的側面及び行動的側面を記載してもよい。例えば、設計モデル１２０は、ＵＭＬ（ユニファイドモデリング言語）クラス図、オブジェクト図、状態遷移図、シーケンス図、及びユースケース図を含んでもよい。あるいは、設計モデル１２０は、ＪＭＬ（Ｊａｖａモデリング言語）、又は他の種類のモデリング言語によって記載されてもよい。バンキングアプリケーション内のオブジェクトの「口座（Account）」クラスの設計モデルの例は、図４のＵＭＬクラス図によって表される。図４に示すように、クラスの名前は「口座（Account）」である。第２の部分において、クラスの属性（別名、メンバー変数）は、個別のラインにリストアップされる。各ラインは、属性名と属性タイプとのペアを示す。第３の部分において、クラスのメソッドは、個別のラインにリストアップされる。各ラインは、括弧内のパラメータリストを有するメソッド名と戻り値のタイプとのペアを示す。

【0023】

テスト制御／実行モジュール１１０は、テスト部品１１６とテスト対象システム１１４との間のインタフェースを提供し、テスト部品１１６によって定義されるようにテストを行う。好適な実施形態において、テスト制御／実行モジュール１１０は、図２に示すように、テスト制御１２２とテスト実行１２４を論理的に含む。テスト制御１２２は、テスト部品１１６内に定義されたオブジェクトの生成、テストの開始及び終了などのテスト動作に対する制御を提供してもよい。テスト実行１２４は、テスト部品１１６によって指定されたテスト行動を実現するためにプログラムコードを実際に実行する少なくともインタプリタ又は仮想マシンによって実現されてもよい。テスト実行１２４は、後述するメタデータ内の変更のために動的な更新をサポートするために、動的クラスローディング及び動的オブジェクトバインディングの能力を持つべきである。

【0024】

設計モデル入力モジュール１０２は、テスト対象システム１１４の設計モデル１２０を記載する入力を受信することができ、且つ設計モデル記憶部２００内に保存された出力データを提供することができる、インタフェースであってもよい。好適な実施形態において、設計モデル入力モジュール１０２は、設計モデル１２０を入力又は編集するために用いることができる、キーボード、ポインティングデバイス、ディスプレイ、及びグラフィカルユーザインタフェースを有するコンピュータ端末である。

【0025】

テスト結果報告モジュール１１２は、映像出力及び／又は音声出力、及び／又はデータ出力を、記憶装置若しくはメモリに対して提供することができる物理的なディスプレイ端末若しくはインタフェースであってもよい。好適な実施形態において、テスト報告モジュール１１２は、テスト制御／実行モジュール１１０に接続されたグラフィカルユーザインタフェースを有するコンピュータ端末である。又は、テスト報告モジュール１１２は、ネットワーク若しくは何らかの通信媒体を介してテスト制御／実行モジュール１１０と通信してもよい。

【0026】

メタデータ記憶部２０３は、図４に示すようなメタデータを記憶する。メタデータは、テスト対象システム１１４内のオブジェクトの構造に関する仕様を提供する１セットのデータである。オブジェクトの構造は、オブジェクトのクラス名と、クラスの属性の名前及びタイプと、クラスのメソッドの名前及び戻り型と、クラスのメソッドの引数の名前及びタイプとを含む。例えば、図４に示すＸＭＬ内に記述されたメタデータのレコードは、図６の設計モデルによって指定されたクラスの属性及びメソッドを伴うクラスの仕様を提供する。図４及び図６の上記の説明、例、及び構成要素は、単に例示的であって、請求項に係る発明を多少なりとも限定するようには意図されない。

【0027】

図１に示されて、図５に更に詳細に示されるメタデータ操作モジュール１０６は、メタデータ１２６、１２８、１３０を生成することができるモジュールである。すなわち、メタデータ操作モジュール１０６は、（ａ）設計モデル１２０から設計書内の各オブジェクトのメタデータ１２６を生成し、（ｂ）テスト対象システム１１４の各オブジェクトからメタデータ１２８を生成し、（ｃ）テスト部品１１６の各オブジェクトからメタデータ１３０を生成する。以降、設計モデル１２０、テスト対象システム１１４及びテスト部品１１６の各々は、システム構成要素を指す。メタデータ操作モジュール１０６は、以下の（ｄ）〜（ｇ）のプロセスを行う能力を更に有する。（ｄ）第１のシステム構成要素として以降称されるシステム構成要素の少なくとも１つに対して行われた修正を検出すること。（ｅ）修正に従って、第１のシステム構成要素のメタデータを更新すること。（ｆ）第２及び第３のシステム構成要素である他の２つのシステム構成要素のメタデータに対して、第１のシステム構成要素のメタデータに対して行われた更新を適用することによって、設計モデル１２０内のメタデータ１２６、テスト対象システム１１４内の対応するオブジェクトのメタデータ１２８、及びテスト部品１１６内の対応するオブジェクトのメタデータ１３０間の整合性を維持すること。（ｇ）第２及び第３のシステム構成要素のメタデータに対して行われた変更を、第２及び第３のシステム構成要素に対してそれぞれ反映すること。

【0028】

例えば、上記のプロセス（ｄ）において、メタデータ操作モジュール１０６は、設計モデル１２０に対する修正を検出する。プロセス（ｅ）において、メタデータ操作モジュール１０６は、修正に従ってメタデータ１２６を更新する。プロセス（ｆ）において、メタデータ操作モジュール１０６は、メタデータ１２６、１２８、１３０間の整合性を維持するためにメタデータ１２８及び１３０を変更する。プロセス（ｇ）において、メタデータ操作モジュール１０６は、メタデータ１２８に対して行われた変更、及びテスト部品１１６に対するメタデータ１３０に対して行われた変更を、テスト対象システム１１４に反映する。

【0029】

プロセス（ａ）、（ｂ）、及び（ｃ）において、メタデータ操作モジュール１０６は、システム構成要素からメタデータを抽出するために、システム構成要素が記述された言語の構文規則を用いてもよい。例えば、メタデータ操作モジュール１０６は、テスト対象システム１１４及びテスト部品１１６がＣ＋＋言語で記述された場合、テスト対象システム１１４及びテスト部品１１６から属性名及び属性タイプを抽出するためにＣ＋＋言語の構文規則を用いる。

【0030】

プロセス（ｄ）において、メタデータ操作モジュール１０６は、システム構成要素を修正するテキストエディタプログラムから通知を受信してもよい。

【0031】

プロセス（ｅ）において、メタデータ操作モジュール１０６は、テキストエディタプログラムから第１のシステム構成要素に対して行われた修正のデータを受信してもよい。その後、第１のシステム構成要素のメタデータに対する修正がどこにどのように行われなければならないのか決定するために、第１のシステム構成要素が記述される言語の構文規則を用いてもよい。メタデータ操作モジュール１０６は、メタデータ１２６内の属性のタイプを変更するためにＵＭＬの構文規則及び意味規則を用いて、属性のタイプが設計モデル１２０内で変更されることを検出する。

【0032】

プロセス（ｆ）において、メタデータ操作モジュール１０６は、メタデータ１２６、１２８及び１３０が対応するオブジェクトごとに同一の構造を記載するように、第２及び第３のシステム構成要素のメタデータを更新する。例えば、対応するメソッドは、各メタデータ１２６、１２８及び１３０内に同一の名前及び同一の戻り型を有する。

【0033】

プロセス（ｇ）において、メタデータ操作モジュール１０６は、第２のシステム構成要素のメタデータの更新版を参照し、第２のシステム構成要素が記述された言語の構文規則を用いてメタデータと第２のシステム構成要素との間の不一致を検出する。そして、メタデータ操作モジュール１０６は、メタデータに従って第２のシステム構成要素を修正する。例えば、第２のシステム構成要素がＣ＋＋言語で記述されたＳＵＴ１１４である場合、メタデータ操作モジュール１０６は、Ｃ＋＋言語の構文規則を用いて、メタデータ１２８内の属性のタイプと、ＳＵＴ１１４のプログラムコード内の属性に対応する変数の定義との間の不一致を検出する。そして、メタデータ操作モジュール１０６は、メタデータ１２８に従って、ＳＵＴ１１４内の定義内の変数のタイプを変更する。メタデータ操作モジュール１０６は、第３のシステム構成要素を同様に処理する。

【0034】

それらの間の不整合性は、設計モデル１２０に対する修正によって、及び／又はテスト対象システム１１４のプログラムコード又はテスト部品１１６のプログラムコードの修正によって、引き起こされ得る。

【0035】

例えば、図４のメタデータは、設計モデル１２０内の口座クラス（class Account）のメタデータ１２６を図示する。テスト対象システム１１４内の口座クラスのプログラムコードとしての実装の場合、メタデータ操作モジュール１０６は、口座クラスの実装のメタデータ１２８から口座クラスの設計モデル１２０のメタデータ１２６への依存関係を維持する。すなわち、テスト対象システム１１４内の口座クラスの各々の実装されるメソッドは、クラスの設計モデル１２０のメソッドのメタデータ１２６の対応する構成要素との関係を有する。また、テスト部品１１６内の「bobAccount」と呼ばれる口座（Account）のインスタンスオブジェクトの場合、メタデータ操作モジュール１０６は、インスタンスオブジェクト「bobAccount」から口座クラスの設計モデル１２０のメタデータ１２６への依存関係を維持する。

【0036】

メタデータ操作モジュール１０６が検出する変更は、設計モデル１２０、テスト対象システム１１４、及びテスト部品１１６内に生じるあらゆる変更を含む。すなわち、設計書内の変更に従って設計モデル１２０内に生じる変更、テスト対象システム１１４のプログラムコードの修正に従ってテスト対象システム１１４内に生じる変更、及びテスト部品１１６のプログラムコードの修正に従ってテスト部品１１６内に生じる変更を含む。

【0037】

メタデータ操作モジュール１０６は、設計モデル１２０、テスト部品１１６、及びテスト対象システム１１４の変更に対してポーリングしてもよい。更に、テスト対象システム１１４及び／又はテスト部品１１６に対して行われた何らかの変更に関して、メタデータ操作モジュール１０６は、テスト制御／実行モジュール１１０に通知してもよい。その結果、モジュール１１０がランタイムオブジェクトを更新してテストを再実行することができる。

【0038】

テストシステム１００の動作を要約するために、ユーザは設計モデル入力モジュール１０２を用いて、設計モデル１２０を生成する。その後、ユーザは、テスト対象システム１１４を実装し、テスト部品１１６を設計通りに生成する。その後、メタデータ操作モジュール１０６は、設計モデル１２０、テスト部品１１６、及びテスト対象システム１１４から、メタデータ１２６、１２８、１３０を生成する。上記の前処理の各々が完了すると、必ずしも上記の順序ではないが、テストシステム１００は、テスト対象システム１１４をテストする準備ができている。

【0039】

第１のテストにおいて、テスト制御／実行モジュール１１０は、テスト部品１１６を読み込み、及びテスト部品１１６によって指定されるように、テストを実行する。テスト部品１１６は、テスト対象システム１１４と相互に作用することによって、例えば、テスト対象システム１１４が提供するＡＰＩを呼び出して、ステップを実行する。各々の行動スクリプトのテスト結果は、テスト結果報告モジュール１１２によってレポートするために記録される。

【0040】

図７は、本発明の自動テストプロセスの動作を記載するフローチャートである。当業者は、テストプロセスが、変更を処理し、テストを中断し開始するために手動介入を要して行われてもよいし、又は、本発明により完全に自動化されたプロセスで行われてもよいことを認識するだろう。更に、本発明は、手動のプロセスと完全に自動化されたプロセスとの両方を組み込むハイブリッド手法が、設計モデル１２０内に生じる変更を処理することを可能にさせる。本質的には、本発明は、設計モデル１２０とメタデータ１２６との関係、テスト１１４下でのシステムの実装におけるメタデータ１２８とオブジェクトとの依存関係、及びテスト部品１１６の実装におけるメタデータ１３０とオブジェクトとの依存関係を定義する。更に、本発明は、変更を反映するための手段としてメタデータ１２６、１２８、１３０を活用する。当業者は、本発明が、完全に自動化されたプロセスが有効でない場合に既知の手動手順と組み合わせた自動プロセスと同様に、自動テストプロセスの提供が適することを認識するだろう。

【0041】

テストシステム１００が処理することができる設計モデル１２０に対する変更は、メソッドの名前及び戻り型の変更、メソッドの署名内のデータ名及び引数のタイプの変更、クラス属性の名前及びタイプの変更、クラスの名前の変更、新たなメソッドの追加、新たな属性の追加、及び既存の属性及びメソッドの除去を含む。テストシステム１００が処理することができるＳＵＴ１１４及びテスト部品１１６に対する変更は、以上に記載されたようなプログラムコード内の構造的な変更を含む。

【0042】

自動テストプロセスは、設計モデル１２０が生成される動作２００から開始する。これは、設計モデル入力モジュール１０２によって行うことができる。動作２０４では、テスト対象システム１１４を設計通りに実装し、その後、動作２０６では、システム行動をテストするためのテスト部品１１６を生成する。

【0043】

その後、動作２０８において、設計モデル１２０、テスト対象システム１１４、及びテスト部品１１６のメタデータ１２６が、メタデータ操作モジュール１０６によって生成される。メタデータ１２６、１２８及び１３０の生成は、ソフトウエアコンポーネントであるトランスフォーマによって実現されてもよい。トランスフォーマは、ソースコードの表現からメタデータ１２６、１２８、１３０のＸＭＬ記述の間を変換する（その逆も成立する）ことができるコンパイラのように機能する。ソースコードの表現は、（ａ）設計モデル１２０の入力フォーマット、（ｂ）ＳＵＴ１１４のプログラムソースコード、又は（ｃ）テスト部品１１６のプログラムソースコードであってもよい。これら３つの表現の各々ごとにトランスフォーマを有してもよい。それぞれのトランスフォーマは、（ａ）設計モデル１２０から設計モデル１２６のメタデータへの間、（ｂ）ＳＵＴ１１４からＳＵＴ１２８のメタデータへの間、及び（ｃ）テスト部品１１６からテスト部品１３０のメタデータへの間をそれぞれ変換する。

【0044】

次に、何らかの試験されていないテスト部品１１６が存在するか否かをテスト制御／実行モジュール１１０が判定する動作２１０において自動テストプロセスが起動される。存在する場合、動作２１２では、試験されていないテスト部品１１６をテストのために読み込み、動作２１４では、テスト部品１１６のテストを実行する。動作２１６では、次に、テスト結果を記録する。テストプロセスは、その後、試験されていないテスト部品１１６が存在するか否かをチェックする動作２１０まで一巡して戻ることによって継続する。テスト部品１１６がすべてテストされた場合、テストプロセスは、終了し、動作２１８では、テスト結果の報告を作成する。

【0045】

図８は、いくつかの変更がソースコードに対して行われる場合のメタデータ操作モジュール１０６の処理フローを表す。本明細書における用語「ソースコード（source）」は、設計モデル１２０又はＳＵＴ１１４又はテスト部品１１６（図５参照）を指してもよい。変更が生じる前の最初は、設計モデル１２６のメタデータ、ＳＵＴ１３０のメタデータ、及びテスト部品１２８のメタデータは、それらがオブジェクトの同一の構造を記載する状態と同じ又は同等である。

【0046】

動作３００では、ソースコード内の変更を検出する。これは、ソースコードの各々に対する何らかの状態変化を観察して自動的に通知するソフトウエアコンポーネントであるオブザーバをバインディングするによって実現することができる。オブザーバは、ソースコードに対して何らかの状態変化の１０６が生じるとメタデータ操作モジュールに通知し、また、変更の前（β）及び後（α）の内容を提供する。変更β及びαの内容は、メタデータを修正する後続の動作によって用いられるだろう。一旦変更が検出されれば、動作３０２では、実行する仮想マシンに休止することを命令することにより、テスト制御／実行モジュール１１０に対してその実行を休止するように命じる。

【0047】

その後、動作３０４では、変更に従ってソースコードのメタデータを修正する。ＳによるソースコードのメタデータのＸＭＬ記述を表すものとする（図４（ａ）のＸＭＬ記述を参照）。動作２０８内に記載されたように、このようなメタデータを生成する対応するトランスフォーマによって、メタデータのＸＭＬ記述に対する変更β及びαの内容を変換によって、動作３０４を実現することができる。
変換は、
β⇒ｍ（β）、
α⇒ｍ（α）、
であり、ここで、ｍ（β）及びｍ（α）は、それぞれ、β及びαのメタデータのＸＭＬ記述であり、その後、ｍ（α）によってｍ（β）に対応するＳの部分を置換する。

【0048】

例えば、設計モデル１２０（ソースコード）に対して変更がなされるケースを図示するものとする。メソッド「credit」の引数「amount」のデータ型は、仕様書内の修正の結果として、整数（Integer）から文字列（String）に変更される。動作３０４では、設計モデル１２６のメタデータを更新する。これは、図４（ｂ）に示すように、<arg type="Integer" name="amount">から<arg type="String" name="amount">に、メタデータの対応するＸＭＬ記述を置換するメタデータ操作モジュール１０６によって行うことができる。

【0049】

動作３０６では、ソースコードではない他の２つのシステム構成要素のメタデータを修正する。同じ方式で、メタデータ操作モジュール１０６は、対応するＳ内の部分を、ｍ（β）をｍ（α）に置換する。先の例から継続すると、メタデータ操作モジュール１０６は、<arg type="Integer" name="amount">から<arg type="String" name="amount">に、メタデータの対応するＸＭＬ記述を置換することによって、ＳＵＴ１２８のメタデータ及びテスト部品１３０のメタデータを修正する。

【0050】

動作３０８では、ソースコード以外の２つのシステム構成要素に対して、メタデータの変更を反映する。動作２０８に記載したように、この動作は、対応するトランスフォーマによって実現することができる。先の例から、ＳＵＴ１１４のトランスフォーマは、変更されたメタデータ１２８から新しい口座クラスを変換する。また、テスト部品１１６のトランスフォーマは、変更されたメタデータ１３０内の新しい口座クラスからインスタンス化された新しいオブジェクトを変換する。

【0051】

一旦変更が反映されれば、動作３１０では、更新されたランタイムオブジェクトを再ロードしてテストの実行を再開するように、動作３０２の実行から休止された仮想マシンに命令する。それによって、動作３１０では、ランタイムオブジェクトを更新するようにテスト制御／実行モジュール１１０に指示する。

【0052】

メタデータ操作モジュール１０６から構成される本発明の実施形態によれば、設計モデル１２０内の変更は、メタデータ１２６、１２８、１３０の変換を通じてテスト対象システム１１４及びテスト部品１１６の実装に反映されることができる。同様に、テスト対象システム１１４の実装内の変更は、メタデータ１２６、１２８、１３０の変換を通じて設計モデル１２０及びテスト部品１１６に反映されることができる。これは、設計書、実装及びテスト部品の間の整合性を維持するためのコスト及び労力を削減することができる。テスト制御／実行モジュール１０６から構成される本発明の実施形態によれば、テスト対象システム１１４又はテスト部品１１６内の修正は、手動の割り込みを伴わずに動的な再バインディングによって、テストにおいて有効になることができる。これは、時間を低減し、テストプロセスを制御するために必要だった配慮を最小限に抑えることができる。

【0053】

本発明の改善された実施形態において、メタデータの１つのみが修正管理装置２００内に存在してもよい。この実施形態において、メタデータ操作モジュール１０６は、（ａ）、（ｂ）及び（ｃ）のプロセスのうちの１つのみを行ってもよく、必ずしもプロセス（ｆ）を行う必要はない。

【0054】

本発明の別の改善された実施形態において、システム構成要素の２つのみが修正管理装置３００内に存在する。例えば、設計モデル１２０及びテスト対象システム１１４のみが、修正管理装置３００内に存在してもよい。

【0055】

＜第２の好ましい実施形態＞
図９を参照すると、第２の好ましい実施形態における修正管理装置３００の簡略ブロック図が表される。修正管理装置３００は、設計モデル記憶部２００と、プログラム記憶部２０１と、メタデータ記憶部２０３と、メタデータ操作部１０６とを備える。

【0056】

設計モデル記憶装置２００は、モデリング言語内のオブジェクトの構造を記載する設計モデル１２０を記憶する。プログラム記憶装置２０１は、テスト対象システムを記憶する。テスト対象システムは、プログラミング言語内のオブジェクトを記載するアプリケーションプログラムである。メタデータ記憶装置２０３は、オブジェクトの構造を記載するメタデータを記憶する。

【0057】

メタデータ操作部１０６は、アプリケーションプログラム及び設計モデル１２０のうちの一方になされた修正から構造内の変更を抽出する。更に、メタデータ操作部１０６は、構造内の変更に従ってメタデータを更新し、更新されたメタデータに従ってアプリケーションプログラム及び設計モデル１２０のうちの他方に対して構造内の変更を反映する。

【0058】

設計書と実装との間の整合性を維持するためのコスト及び負担が軽減される。これは、メタデータ操作モジュール１０６により、設計モデル１２０内の変更がメタデータの変換を通じてテスト対象システム１１４の実装に反映され得る（その逆も成立する）からである。

【産業上の利用可能性】

【0059】

本発明は、コンピュータソフトウェアのテストの自動化用に用いることができるが、特にアジャイルソフトウェア開発には限定されない。本発明は、テスト対象システムの機能仕様書とテスト仕様書との間の整合性をチェックするために用いることができる。

【符号の説明】

【0060】

１００ テストシステム
１０２ 設計モデル入力モジュール
１０６ メタデータ操作モジュール
１１０ テスト制御／実行モジュール
１１２ テスト結果報告モジュール
１１４ テスト対象システム
１１６ テスト部品
１２０ 設計モデル
１２２ テスト制御
１２４ テスト実行
１２６ 設計モデルのメタデータ
１２８ テスト部品のメタデータ
１３０ テスト対象システムのメタデータ
２００ 設計モデル記憶部
２０１ プログラム記憶部
２０２ テスト部品記憶装置
２０３ メタデータ記憶部
３００ 修正管理装置

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】