図面 (/)

技術 ソフトウェア成果物の第2バージョンに移行する際に、当該ソフトウェア成果物の第1バージョンになされたカスタマイズをマージするためのツールを生成する方法、コンピュータ使用可能な媒体及びデータ処理システム

出願人 インターナショナル・ビジネス・マシーンズ・コーポレーション
発明者 ブルース・アール・ベイカーチェンフェイ・ソンユー・ユエンウォルフレイ・ング
出願日 2009年9月24日 (10年9ヶ月経過) 出願番号 2009-219374
公開日 2010年4月8日 (10年2ヶ月経過) 公開番号 2010-079905
状態 特許登録済
技術分野 ストアードプログラム ストアードプログラム
主要キーワード 補完要素 消費モジュール 要素シーケンス 先行バージョン 解析対象外 構造化プログラミング言語 保守中 文字参照
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2010年4月8日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (6)

課題

ソフトウェア成果物の第2バージョン移行する際に、当該ソフトウェア成果物の第1バージョンになされたカスタマイズマージするためのツールを生成する方法を提供する。

解決手段

第2コード・セット内に補完要素を有していない第1コード・セット内の最上位要素ごとに、一のマッピング要素インスタンス化するステップと、前記マッピング要素内にマージ命令が提供されていない最上位要素ごとに、マージ命令を要求し且つ受け取るステップと、マージ命令が提供されている最上位要素ごとに、当該マージ命令がカスタマイズを前記第2コード・セットにマージすることを必要とするかを決定するステップと、カスタマイズをマージすることを必要とする各最上位要素用の前記マージ命令が有効であるかを決定するステップと、最上位要素ごとに受け取られた前記マージ命令を前記マッピング要素内に格納するステップを含む。

概要

背景

バージョン管理は、データ・ファイル及びソフトウェアの異なるバージョン及びバリアントを管理することを意味する。ソフトウェアが開発され、設計され、展開されるにつれて、同じソフトウェアの複数のバージョンが異なるサイトに導入されたり、ソフトウェアの開発者がそれぞれの更新を同時に実行することが極めて一般的となっている。コード再利用(すなわち、ソフトウェアを更新するか又は新しいソフトウェアを実装するために、既存のソフトウェアを利用すること)は、或る時点で書かれたコンピュータプログラムの一部又は全部を、その後書かれる他のプログラム内で利用することが可能である、又は利用すべきであるという着想に基づいている。プログラマは、冗長開発作業を減少させることを通して時間及びエネルギーを節約するために、プログラミングの最も初期の時期から、コード、テンプレート、機能及びプロシージャの一部を再利用してきた。最も一般的な再利用は、ソフトウェア・コンポーネントの再利用であるが、ソフトウェア開発プロセス中に作成されたシステムアーキテクチャ分析モデル設計モデル設計パターンデータベーススキーマウェブサービス等の他の成果物(artifact)も再利用することができる。次期バージョン用の土台として既存プログラム先行バージョンを使用するという一般的な開発プラクティスは、コード再利用の標準的な形式である。

コード再利用の一般的な例は、エンド・ユーザ開発(EUD)、すなわち専門の開発者でないエンド・ユーザがソフトウェア成果物を作成又は変更することを可能にするという活動又は技術である。EUDは、本質的に、開発努力をエンド・ユーザに外注することと見なすことができる。EUDの一般的な事例は、既存のアプリケーションパッケージ(例えば、オフィス・パッケージ)を拡張し且つ適応させるようにプログラムすることである。EUDが普及した2つの主な理由は、プロジェクト完成期日を有効に短縮するために諸組織がEUDを使用できるという点と、ソフトウェア・ツールがより強力で且つより使いやすいという点にある。

概要

ソフトウェア成果物の第2バージョンに移行する際に、当該ソフトウェア成果物の第1バージョンになされたカスタマイズマージするためのツールを生成する方法を提供する。第2コード・セット内に補完要素を有していない第1コード・セット内の最上位要素ごとに、一のマッピング要素インスタンス化するステップと、前記マッピング要素内にマージ命令が提供されていない最上位要素ごとに、マージ命令を要求し且つ受け取るステップと、マージ命令が提供されている最上位要素ごとに、当該マージ命令がカスタマイズを前記第2コード・セットにマージすることを必要とするかを決定するステップと、カスタマイズをマージすることを必要とする各最上位要素用の前記マージ命令が有効であるかを決定するステップと、最上位要素ごとに受け取られた前記マージ命令を前記マッピング要素内に格納するステップを含む。

目的

EUDの一般的な事例は、既存のアプリケーション・パッケージ(例えば、オフィス・パッケージ)を拡張し且つ適応させるようにプログラムすることである

効果

実績

技術文献被引用数
1件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

ソフトウェア成果物の第2バージョン移行する際に、当該ソフトウェア成果物の第1バージョンになされたカスタマイズマージするためのツールを生成する方法であって、前記第2バージョン用の第2コード・セット内に相補的データ要素を有していない前記第1バージョン用の第1コード・セット内の最上位データ要素ごとに、一のマッピング情報要素を第1データ・ストア内でインスタンス化するステップと、前記対応するマッピング情報要素内にマージ命令が提供されていない前記第1コード・セット内の最上位データ要素ごとに、当該最上位データ要素用のマージ命令を要求するステップと、マージ命令が提供されていない前記第1コード・セット内の最上位データ要素ごとに、マージ命令を受け取るステップと、マージ命令が提供されている前記第1コード・セット内の最上位データ要素ごとに、当該マージ命令が、当該最上位データ要素になされたカスタマイズを前記第2コード・セットにマージすることを必要とするか否かを決定するステップと、前記第1コード・セット内の各最上位データ要素になされたカスタマイズをマージすることを必要とする当該最上位データ要素用のマージ命令が、有効であるか否かを決定するステップと、前記マージ命令が有効でないと決定された前記第1コード・セット内の最上位データ要素ごとに、マージ命令を要求するステップと、前記マージ命令が有効でないと決定された前記第1コード・セット内の最上位データ要素ごとに、マージ命令を受け取るステップと、前記第1コード・セット内の最上位データ要素ごとに受け取られた前記マージ命令を、前記第1データ・ストア内の前記対応するマッピング情報要素内に格納するステップを含む、方法。

請求項2

前記第2コード・セット内に相補的データ要素を有していない前記第1コード・セット内の各最上位データ要素の子孫データ要素ごとに、一のマッピング情報要素を前記第1データ・ストア内で生成するステップをさらに含む、請求項1に記載の方法。

請求項3

前記第1コード・セット内の各最上位データ要素になされたカスタマイズをマージすることを必要としない当該最上位データ要素の子孫データ要素ごとに、マージ命令を生成し且つ当該子孫データ要素になされたカスタマイズをマージする必要がないことを指定するステップと、前記第1コード・セット内の各最上位データ要素になされたカスタマイズをマージすることを必要としない当該最上位データ要素の子孫データ要素ごとに生成された、前記マージ命令を格納するステップをさらに含む、請求項2に記載の方法。

請求項4

前記マージ命令が有効であると決定された前記第1コード・セット内の最上位データ要素ごとに、当該マージ命令を、前記第1データ・ストア内の前記対応するマッピング情報要素内に格納するステップをさらに含む、請求項2に記載の方法。

請求項5

前記マージ命令が有効であると決定された前記第1コード・セット内の各最上位データ要素の子データ要素ごとに、マージ命令を生成するステップと、前記マージ命令が有効であると決定された前記第1コード・セット内の各最上位データ要素の各子データ要素用の前記マージ命令が、有効であるか否かを決定するステップと、前記マージ命令が有効でないと決定された前記第1コード・セット内の各最上位データ要素の子データ要素ごとに、マージ命令を要求するステップと、前記マージ命令が有効でないと決定された前記第1コード・セット内の各最上位データ要素の子データ要素ごとに、マージ命令を受け取るステップと、前記マージ命令が有効でないと決定された前記第1コード・セット内の各最上位データ要素の子データ要素ごとに受け取られた前記マージ命令を、前記第1データ・ストア内の前記対応するマッピング情報要素内に格納するステップと、前記マージ命令が有効であると決定された前記第1コード・セット内の各最上位データ要素の子データ要素ごとに、当該マージ命令を、前記第1データ・ストア内の前記対応するマッピング情報要素内に格納するステップをさらに含む、請求項4に記載の方法。

請求項6

前記第1コード・セット内の各最上位データ要素になされたカスタマイズをマージすることを必要としない当該最上位データ要素の子孫データ要素ごとに、マージ命令を生成し且つ当該子孫データ要素になされたカスタマイズをマージする必要がないことを指定するステップと、前記第1コード・セット内の各最上位データ要素になされたカスタマイズをマージすることを必要としない当該最上位データ要素の各子孫データ要素用の前記マージ命令を格納するステップをさらに含む、請求項5に記載の方法。

請求項7

前記第2コード・セット内に相補的データ要素を有していない前記第1コード・セット内の各データ要素になされたカスタマイズを当該データ要素用の前記対応するマッピング情報要素に従ってマージするために、前記第1コード・セットを前記第2コード・セットに移行させる場合にアクセス可能な機能性を提供するように、前記第1データ・ストア内の前記マッピング情報要素を一のアプリケーションプログラミングインタフェース内でラップするステップをさらに含む、請求項6に記載の方法。

請求項8

前記マッピング情報要素及び前記アプリケーション・プログラミング・インタフェースが、前記第1コード・セットから前記第2コード・セットへの移行を実行するように構成された一の移行ツール内に組み込まれる、請求項7に記載の方法。

請求項9

前記第1データ・ストア内の各マッピング情報要素が、対応するデータ要素が位置する、前記第1コード・セット内の第1ファイル名前値用の第1フィールドと、前記対応するデータ要素が位置する、前記第1ファイル内の第1位置値用の第2フィールドと、前記第1コード・セット内の前記対応するデータ要素になされたカスタマイズを前記第2コード・セットにマージすべきか否かを指示する、キー値用の第3のフィールドと、前記対応するデータ要素になされたカスタマイズをマージすべき、前記第2コード・セットの第2ファイルの第2名前値用の第4のフィールドと、前記対応するデータ要素になされたカスタマイズをマージすべき、前記第2ファイル内の第2位置値用の第5のフィールドを含む、請求項1に記載の方法。

請求項10

前記第2コード・セット内に相補的データ要素を有していない前記第1コード・セット内の各最上位データ要素を識別するために、前記第1コード・セットを前記第2コード・セットと比較するステップをさらに含む、請求項1に記載の方法。

請求項11

前記比較するステップが、前記第1コード・セットを、固有識別子によって識別される前記第1コード・セット内のデータ要素ごとに一のコンテキスト要素を含む、第1コンテキスト・オブジェクト並列化するステップと、前記第2コード・セットを、固有識別子によって識別される前記第2コード・セット内のデータ要素ごとに一のコンテキスト要素を含む、第2コンテキスト・オブジェクトに並列化するステップと、前記第1コンテキスト・オブジェクト内の各コンテキスト要素を前記第2コンテキスト・オブジェクト内の各コンテキスト要素と比較するステップを含む、請求項10に記載の方法。

請求項12

前記第1コード・セット及び前記第2コード・セットが、SGML、XML、HTML、WML、XHTML、DHTML、他のSGML派生言語及びユーザ・インタフェース・マークアップ言語から選択された、構造化プログラミング言語文書から成る、請求項1に記載の方法。

請求項13

前記第1コード・セット及び前記第2コード・セットが、XMLスキーマによって定義されていないXML言語の文書から成り、前記第1コード・セット及び前記第2コード・セット内の各データ要素が、一のXML要素である、請求項12に記載の方法。

請求項14

前記ソフトウェア成果物が、1つ以上のソフトウェアコンポーネント、システムアーキテクチャ、アプリケーション・パッケージ分析モデル設計モデル設計パターンデータベーススキーマ及びウェブサービスである、請求項1に記載の方法。

請求項15

前記方法が、前記第2バージョンの開発中に定期的に実行される、請求項1に記載の方法。

請求項16

前記第2コード・セットを作成するように、前記第1コード・セット上でコード・リファクタリングが実行された、請求項1に記載の方法。

請求項17

前記マージ命令を要求するステップ及び前記マージ命令を受け取るステップが、一のユーザ・インタフェースを介して一のマージ命令要求を生成するステップと、ユーザ入力によって提供された一のマージ命令指定を、前記ユーザ・インタフェースを介して受け取るステップを含む、請求項1に記載の方法。

請求項18

ソフトウェア成果物の第2バージョンに移行する際に、当該ソフトウェア成果物の第1バージョンになされたカスタマイズをマージするためのツールを生成する方法を一のプロセッサに実行させる、コンピュータ可読命令を記録したコンピュータ使用可能な媒体であって、前記方法が、前記第2バージョン用の第2コード・セット内に相補的データ要素を有していない前記第1バージョン用の第1コード・セット内の最上位データ要素ごとに、一のマッピング情報要素を第1データ・ストア内でインスタンス化するステップと、前記対応するマッピング情報要素内にマージ命令が提供されていない前記第1コード・セット内の最上位データ要素ごとに、当該最上位データ要素用のマージ命令を要求するステップと、マージ命令が提供されていない前記第1コード・セット内の最上位データ要素ごとに、マージ命令を受け取るステップと、マージ命令が提供されている前記第1コード・セット内の最上位データ要素ごとに、当該マージ命令が、当該最上位データ要素になされたカスタマイズを前記第2コード・セットにマージすることを必要とするか否かを決定するステップと、前記第1コード・セット内の各最上位データ要素になされたカスタマイズをマージすることを必要とする当該最上位データ要素用のマージ命令が、有効であるか否かを決定するステップと、前記マージ命令が有効でないと決定された前記第1コード・セット内の最上位データ要素ごとに、マージ命令を要求するステップと、前記マージ命令が有効でないと決定された前記第1コード・セット内の最上位データ要素ごとに、マージ命令を受け取るステップと、前記第1コード・セット内の最上位データ要素ごとに受け取られた前記マージ命令を、前記第1データ・ストア内の前記対応するマッピング情報要素内に格納するステップを含む、コンピュータ使用可能な媒体。

請求項19

データ処理システムであって、少なくとも1つのプロセッサと、データ及び前記少なくとも1つのプロセッサによって実行すべきプログラムを格納するためのランダムアクセスメモリと、ソフトウェア成果物の第2バージョンに移行する際に、当該ソフトウェア成果物の第1バージョンになされたカスタマイズをマージするためのツールを生成する方法を前記少なくとも1つのプロセッサに実行させる、前記ランダム・アクセス・メモリ内に格納されたコンピュータ可読命令を備え、前記方法が、前記第2バージョン用の第2コード・セット内に相補的データ要素を有していない前記第1バージョン用の第1コード・セット内の最上位データ要素ごとに、一のマッピング情報要素を第1データ・ストア内でインスタンス化するステップと、前記対応するマッピング情報要素内にマージ命令が提供されていない前記第1コード・セット内の最上位データ要素ごとに、当該最上位データ要素用のマージ命令を要求するステップと、マージ命令が提供されていない前記第1コード・セット内の最上位データ要素ごとに、マージ命令を受け取るステップと、マージ命令が提供されている前記第1コード・セット内の最上位データ要素ごとに、当該マージ命令が、当該最上位データ要素になされたカスタマイズを前記第2コード・セットにマージすることを必要とするか否かを決定するステップと、前記第1コード・セット内の各最上位データ要素になされたカスタマイズをマージすることを必要とする当該最上位データ要素用のマージ命令が、有効であるか否かを決定するステップと、前記マージ命令が有効でないと決定された前記第1コード・セット内の最上位データ要素ごとに、マージ命令を要求するステップと、前記マージ命令が有効でないと決定された前記第1コード・セット内の最上位データ要素ごとに、マージ命令を受け取るステップと、前記第1コード・セット内の最上位データ要素ごとに受け取られた前記マージ命令を、前記第1データ・ストア内の前記対応するマッピング情報要素内に格納するステップを含む、データ処理システム。

技術分野

0001

本発明は、ソフトウェア保守係り、さらに詳細に説明すれば、マージ能力を含む改訂管理ソフトウェア・ツールに係る。

背景技術

0002

バージョン管理は、データ・ファイル及びソフトウェアの異なるバージョン及びバリアントを管理することを意味する。ソフトウェアが開発され、設計され、展開されるにつれて、同じソフトウェアの複数のバージョンが異なるサイトに導入されたり、ソフトウェアの開発者がそれぞれの更新を同時に実行することが極めて一般的となっている。コード再利用(すなわち、ソフトウェアを更新するか又は新しいソフトウェアを実装するために、既存のソフトウェアを利用すること)は、或る時点で書かれたコンピュータプログラムの一部又は全部を、その後書かれる他のプログラム内で利用することが可能である、又は利用すべきであるという着想に基づいている。プログラマは、冗長開発作業を減少させることを通して時間及びエネルギーを節約するために、プログラミングの最も初期の時期から、コード、テンプレート、機能及びプロシージャの一部を再利用してきた。最も一般的な再利用は、ソフトウェア・コンポーネントの再利用であるが、ソフトウェア開発プロセス中に作成されたシステムアーキテクチャ分析モデル設計モデル設計パターンデータベーススキーマウェブサービス等の他の成果物(artifact)も再利用することができる。次期バージョン用の土台として既存プログラム先行バージョンを使用するという一般的な開発プラクティスは、コード再利用の標準的な形式である。

0003

コード再利用の一般的な例は、エンド・ユーザ開発(EUD)、すなわち専門の開発者でないエンド・ユーザがソフトウェア成果物を作成又は変更することを可能にするという活動又は技術である。EUDは、本質的に、開発努力をエンド・ユーザに外注することと見なすことができる。EUDの一般的な事例は、既存のアプリケーションパッケージ(例えば、オフィス・パッケージ)を拡張し且つ適応させるようにプログラムすることである。EUDが普及した2つの主な理由は、プロジェクト完成期日を有効に短縮するために諸組織がEUDを使用できるという点と、ソフトウェア・ツールがより強力で且つより使いやすいという点にある。

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

0004

しかし、EUDの実装上の欠点は、ソフトウェア保守(すなわち、ソフトウェア製品の引き渡し後に、障害訂正するか、性能又は他の属性を改良するか、又は当該製品変更済みの環境に適応させるために、当該製品を変更することを含む活動又は技術)の複雑さを増加させる場合があるという点にある。特に、エンド・ユーザがプログラミング・コードに個別的なカスタマイズをなした場合、実装のプロセス及び変更されたバージョンの製品受容を考慮すると、当該コードの元の開発者がこれらのカスタマイズの責任を持つことは困難である。

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

0005

本発明の第1側面によれば、ソフトウェア成果物の第2バージョンに移行する際に、当該ソフトウェア成果物の第1バージョンになされたカスタマイズをマージするためのツールを生成する方法が提供される。本方法は、次のステップを含む。
即ち、前記第2バージョン用の第2コード・セット内に相補的データ要素(complementarydata element)を有していない前記第1バージョン用の第1コード・セット内の最上位データ要素(top-leveldata element)ごとに、一のマッピング情報要素を第1データ・ストア内でインスタンス化するステップ;
前記対応するマッピング情報要素内にマージ命令が提供されていない前記第1のコード・セット内の最上位データ要素ごとに、当該最上位データ要素用のマージ命令を要求するステップ;
マージ命令が提供されていない前記第1のコード・セット内の最上位データ要素ごとに、マージ命令を受け取るステップ;
マージ命令が提供されている前記第1のコード・セット内の最上位データ要素ごとに、当該マージ命令が、当該最上位データ要素になされたカスタマイズを前記第2のコード・セットにマージすることを必要とするか否かを決定するステップ;
前記第1のコード・セット内の各最上位データ要素になされたカスタマイズをマージすることを必要とする当該最上位データ要素用のマージ命令が、有効であるか否かを決定するステップ;
前記マージ命令が有効でないと決定された前記第1のコード・セット内の最上位データ要素ごとに、マージ命令を要求するステップ;
前記マージ命令が有効でないと決定された前記第1のコード・セット内の最上位データ要素ごとに、マージ命令を受け取るステップ;
前記第1のコード・セット内の最上位データ要素ごとに受け取られた前記マージ命令を、前記第1のデータ・ストア内の前記対応するマッピング情報要素内に格納するステップを含む。

0006

本発明の他の側面によれば、前述の方法に対応するコンピュータ・プログラム及びデータ処理システムが提供される。

発明の効果

0007

本発明は、現バージョンになされたカスタマイズを新バージョンに自動的にマージするために生成されるツールが、開発者による最小量の入力だけを必要とし、その結果、旧バージョン及び新バージョンのリリースの間に相当な量のコード・リファクタリングが実行された場合でさえ、開発コストを著しく減少させることができるという効果を奏する。

図面の簡単な説明

0008

本発明に従った、マージ・ソリューション・ツール・フレームワークの実施形態を示すブロック図である。
図1の要素モニタサブコンポーネントを示すブロック図である。
本発明に従った、2つの異なるXMLファイル内にある2つのXML要素を比較するプロセスを示すフローチャートである。
本発明に従った、マージ・ソリューション・ツールを生成するプロセスを示すフローチャートである。
本発明の実施形態を実装するために使用することができるコンピュータ・システムを示すブロック図である。

実施例

0009

新規であると想定される本発明の特徴は、請求項において定義されているが、実施形態に係る以下の説明及び図面を参照すれば、本発明を一層よく理解することができるであろう。本発明は、種々の形態で実施することができるから、本明細書に開示した実施形態は、本発明の例示であるに過ぎない。従って、実施形態について開示した特定の構造的及び機能的な詳細事項は、本発明を制限するものとして解釈すべきではなく、本発明を任意の適切な形態で使用することを当業者に教示するための代表的な基礎として解釈すべきである。

0010

本発明の実施形態(以下「実施形態」と表記)が提供する機構は、ソフトウェア成果物の新バージョンの開発中に、当該ソフトウェア成果物の現バージョン用のコードになされた変更をモニタするとともに、当該ソフトウェア成果物の現バージョン用のコード内に存在するデータ要素が当該ソフトウェア成果物の新バージョン内に相補的なデータ要素を有していないという事例ごとに、第3者が現バージョン用のコードになしたカスタマイズをマージするためのソリューションを提供する自動化ツールを生成するように、定期的に使用することができる。これらの事例ごとに、カスタマイズをマージするためのソリューションを提供することにより、実施形態は、ソフトウェア成果物のコードが現バージョンと新バージョンとの間で著しくリファクタリングされた場合でさえ、当該ソフトウェア成果物の現バージョンのデータ要素になされたカスタマイズを新バージョンに自動的にマージするためのツールを生成するように動作することができる。本明細書において、「データ要素」という用語は、データ要素名、データ要素定義及び1つ以上の表記用語のような識別子を含む、データの原子単位を意味する。

0011

本明細書において、ソフトウェア成果物の現バージョン内に存在するデータ要素が当該ソフトウェア成果物の新バージョン内に相補的データ要素を有していないと称するのは、当該データ要素が当該ソフトウェア成果物の新バージョン内にもはや存在しないか、又は新バージョン内で異なった態様で構造化される場合である。具体的には、現バージョンと新バージョンとの間に、次の5つの相違点のうちの1つが存在する場合である。(1)当該データ要素は、両バージョン間で削除された、(2)当該データ要素は、現バージョンと同じ構造化プログラミング言語文書内に存在するが、新バージョン内の異なる親(parent)要素に関連付けられている、(3)当該データ要素は、異なる構造化プログラミング言語文書内に存在し且つ新バージョン内の異なる親要素に関連付けられている、(4)当該データ要素は、同じ親要素と関連付けられているが、新バージョン内の異なる構造化プログラミング言語文書内に存在する、(5)当該データ要素は、新バージョン内でリネームされた。

0012

実施形態では、ソフトウェア成果物の現バージョン用のコードになされたカスタマイズを自動的にマージするために生成されるツールは、当該ソフトウェア成果物の現バージョン内に存在するが当該ソフトウェア成果物の新バージョン内に相補的データ要素を有していないデータ要素になされたカスタマイズを調整するためのマージ・ソリューションのデータ・ストアと、現バージョンから新バージョンへのコード移行を実行する際に自動化データ移行ツールアクセス可能であり且つユーザが現バージョン用のコードになしたカスタマイズによって指示されるように前記マージ・ソリューションにサービスするインタフェースを提供することができる。本明細書において、「データ・ストア」という用語は、マニュアル・ファイル、コンピュータ可読ファイル及びデータベースを含む、データを格納するために使用することができる任意の適切なメモリ装置を意味する。実施形態は、次のように実装することができる。すなわち、現バージョンになされたカスタマイズを新バージョンに自動的にマージするために生成されるツールが、最小量の開発者入力だけを必要とし、その結果、旧バージョン及び新バージョンのリリースの間に相当な量のコード・リファクタリングが実行された場合でさえ、開発コストを著しく減少させることができる。

0013

以上で概説した前記機構については、前記ソフトウェア成果物がXMLスキーマによって定義されていないXML文書の形式を有する構造化文書から成り且つ当該XML文書が順序付き(ordered)又は順序なし(unordered)の多数の要素を含むように意味制約(semantic constraint)に従ってフォーマットされた実施形態を参照して、以下で詳細に説明する。もちろん、このシナリオは例示であるに過ぎない。というのは、実施形態は、XML言語文書だけでなく、任意のタイプの構造化文書から成るソフトウェア成果物にも適用することができるからである。実施形態が適用可能なソフトウェア成果物は、種々の構造化言語、例えば、HTML、WML、XHTML、DHTML又は他のSGM派生言語、並びにユーザ・インタフェース・マークアップ言語(例えば、UIML、XAL、SVG、XAML及びLZX)のような他の構造化言語、パスカル及びCのようなプログラミング言語、2次元又は3次元のレイアウトを定義するために使用される言語等でコード化した文書から成る。また、実施形態は、科学情報、エンジニアリング情報経済情報、ゲーム、暗号等を格納するために使用される構造化言語でコード化した文書から成るソフトウェア成果物にも適用することができる。一般に、構造化言語で書かれた文書は、諸要素の階層構造を有し、その構造はタグ(すなわち、当該文書内の文字シーケンス)によって定義される。さらに、実施形態は、ソフトウェア・コンポーネント、システム・アーキテクチャ、アプリケーション・パッケージ、分析モデル、設計モデル、設計パターン、データベース・スキーマ、ウェブ・サービス等のような、任意の適切なタイプのソフトウェア成果物に適用することができる。

0014

XML標準は、WWWコンソーシアム(W3C)によって管理され、W3Cのウェブ・サイト上で維持管理される。XMLは、XML文書と呼ばれるデータ・オブジェクトクラスを記述し、それらを処理するコンピュータ・プログラムの振る舞いを一部記述する。XML文書は、数々の要素の集合を含む自己記述型の構造化文書であり、自動的な意味的統合の形式に対して都合が良い場合がある。従って、本明細書において、「XML要素」又は「XMLデータ要素」という用語は、XMLの諸規則によって定義されるような、1セットのブラケット間に含まれるコード語を意味する。XMLが拡張可能言語として分類されるのは、ユーザが(解析対象データ又は解析対象外データを含む)ユーザ自体の要素を定義することを可能にするためである。解析対象データは、諸文字から構成され、そのうちの或るものは文字データを形成し、そのうちの或るものはマークアップを形成する。各要素は、関連する属性及び要素のリストを有することがある。或る要素は、他の要素を文書内に組み込ませるために、当該他の要素を参照することがある。或る文書は、或る「ルート」又は文書要素内で開始する。マークアップは、文書のストレージ・レイアウト及び論理構造の記述をエンコードする。論理上、この文書は、宣言、要素、コメント文字参照及び処理命令から成り、それらの全ては明示的なマークアップによって当該文書内に指示される。XMLは、ストレージ・レイアウト及び論理構造に制約課すための機構を提供する。これらの意味制約を追加することにより、アプリケーション言語は、XMLで実装することができる。

0015

以下に例示するシナリオは、XMLスキーマが定義されていないカスタマイズ可能なXML文書を含むソフトウェア成果物をマージすることに係り、当該ソフトウェア成果物の保守中に生じることがある幾つかの問題を示す(なお、実施形態は、これらの問題に対処するために実装することができる)。このシナリオでは、ソフトウェア・ベンダは、最初に、1セットのカスタマイズ可能なXML文書を含むアプリケーション・パッケージ用のコードの「バージョン1」を作成する。前記XML文書は、指定された意味制約に従って提供されるが、前記XML文書については、XMLスキーマは定義されていない。ユーザが、前記アプリケーション・パッケージのバージョン1を購入し、前記XML文書の意味構造を理解した上で、前記XML文書の諸要素を変更することにより、前記アプリケーション・コードをカスタマイズする。また、前記ユーザは、前記カスタマイズ可能なXML文書内で使用するための新しい要素を定義することができる。その後、前記ベンダは、新しい機能性を追加することにより、前記アプリケーション・パッケージを拡張することを決定する。前記新しい機能性のうちの或るものは、前記カスタマイズ可能なXML文書への更新を通して実装されるであろう。

0016

前記アプリケーション・パッケージを更新する前に、前記ベンダは、当該パッケージの「バージョン1」用のコードをリファクタリングすることを決定する。一般に、コード・リファクタリング(非公式には、「クリーンアップ」とも呼ばれる)は、プログラムに新しい機能性を追加したり、当該プログラム内のバグ修正することが困難である場合に動機づけられるものであって、プログラミング・コードの既存の機能性を維持しつつ、変更に適応しやすくし、可読性を改良し、又は構造を単純化するように、プログラミング・コードを変更するプロセスを意味する。例えば、コード・リファクタリングは、コードの内部構造及び設計を変更し且つ不要コード及び他のコード肥大を除去することによって、コードの分かりやすさを改良するために使用することができる。単純なリファクタリングの1例は、可変名を単一文字の「i」から一層意味のある「interestRate」という文字シーケンスに変更する場合のように、識別子として使用すべき文字シーケンスを変更するというものである。

0017

リファクタリングを実行し且つ新しい機能性を前記コードに追加した後、前記アプリケーション・パッケージの更新済みバージョン、すなわち「バージョン2」用の前記ベンダのコードは、バージョン1に基づく。次に、前記ユーザは、前記アプリケーション・パッケージのバージョン2にアップグレードすることを決定する。前記ユーザは、前記カスタマイズを失うことなくバージョン2の新しい機能を獲得するために、バージョン1内の前記XML文書をカスタマイズしたのであるから、前記ユーザがバージョン1用の前記XML文書になした諸変更は、バージョン2のXML文書にマージする必要があろう。しかし、前記リファクタリングのために、バージョン1内に存在していた幾つかの要素は、バージョン2内にもはや存在しないか、又はバージョン2内で異なった態様で構造化されることがある。その結果、前記ユーザがカスタマイズした前記アプリケーション・パッケージのバージョン1用のコードの要素が、バージョン2内にもはや存在しないか、又はバージョン2内で異なった態様で構造化されることがあり、従って、従来技術のマージ技術を使用する場合は、これらのカスタマイズを手動的に統合する必要があろう。これに対し、実施形態は、たとえ前記アプリケーション・パッケージのコードがバージョン1とバージョン2との間でリファクタリングの処理対象となったとしても、バージョン2内にもはや存在しないか、又はバージョン2内で異なった態様で構造化される、バージョン1用のコードの要素になされたカスタマイズを自動的にマージするためのツールを提供することができる。

0018

実施形態は、新バージョンのリリースまで、ソフトウェア成果物の現バージョン用のコードになされたカスタマイズを新バージョンにマージするための生成済みソリューションに関する検証を定期的に実行することにより、当該ソリューションの正確さを検証するように実装することができる。このアプローチは、リリース後の保守コストの点で、有利となることがある。このアプローチのエラー出現頻度は、(1)新バージョンに移行した後に、ユーザがそのカスタマイズを再実装することを必要とするという手動的アプローチ、又は(2)新バージョンの開発中に、開発者が現バージョン用のコードになされた更新を手動的にモニタし、そして新バージョンに移行する間又はその後にユーザが現バージョン・コードへのその変更を新バージョン・コードに手動的にマージする際に当該ユーザが順守すべき指示を文書化することを必要とするという手動的アプローチに比べて、遙かに小さくなる。特に、このことが顕著であるのは、ソフトウェア成果物が大きな開発チームによって作成され、そして多数のファイルを含むような場合である。

0019

図1は、本発明に従った、マージ・ソリューション・ツール・フレームワーク100の実施形態を示す。後述するように、マージ・ソリューション・ツール・フレームワーク100は、1セットのカスタマイズ可能なXML文書を含むソフトウェア成果物の新バージョン用のXMLコード・ファイルを開発する間に、当該ソフトウェア成果物の現バージョンのXMLコード・ファイルになされた変更をモニタし、また前記現バージョン用のXML文書内に存在していたが前記新バージョン用のXML文書内に相補的XML要素を有していないXML要素ごとに、第3者が前記現バージョン用のカスタマイズ可能なXML文書になしたカスタマイズをマージするためのソリューションを提供する自動化ツールを生成する。マージ・ソリューション・ツール・フレームワーク100は、前記自動化ツールが提供するマージ・ソリューションを更新することにより、両バージョン間でなされた変更を連続的に統合するために、ソフトウェア開発サイクル中に定期的に使用することができる機構を提供する。

0020

マージ・ソリューション・ツール・フレームワーク100は、最上位要素モニタ・モジュール(以下「要素モニタ」と表記)110、マージ資源モジュール(以下「マージ資源」と表記)120、マージ・ソリューション検証モジュール(以下「検証手段」と表記)130、マージ・ソリューション作成モジュール(以下「ソリューション作成手段」と表記)140、マージ要求作成モジュール(以下「要求作成手段」と表記)150、マージ・ソリューション消費モジュール(以下「ソリューション消費手段」と表記)160及びマージ・インタフェース作成モジュール(以下「マージ・インタフェース」と表記)170を含む。本明細書において、「モジュール」及び「プログラム・モジュール」という用語は、特定のタスクを実行するか又は特定の抽象データ・タイプを実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造命令又は命令セット等を意味する。これらのモジュールは、記述された機能性を提供するソフトウェア、ハードウェアファームウェア、又は他の適切なコンポーネントとして実装することができ、そして本発明に従ったバージョン比較機構の実施形態を具体化するコンピュータのメモリにロードすることができる。これらのモジュールの諸側面は、C、C++、Java(登録商標)等の種々のプログラミング言語で書くことができる。これらのモジュールによって提供される機能性は、これを組み合わせたり、分割することができる。

0021

一般に、要素モニタ110は、後日にリリースするためにソフトウェア成果物の新バージョンが開発されている間に、当該ソフトウェア成果物の現バージョン内に存在し且つ新バージョン内に相補的XML要素を有していない最上位(親)XML要素を識別するように、開発を定期的にモニタする。XML文書は、正確に1つのルート要素を有する、ツリーベース意味論的構造を含む。以下で詳述するように、要素モニタ110によって識別される最上位XML要素は、ソフトウェア成果物の現バージョン内に存在し且つ新バージョン内に相補的XML要素を有していないXML文書の全てのXML要素であって、さらに新バージョン内に相補的XML要素を有していない先祖(ancestor)要素をXML文書のツリー構造内に有していないものである。

0022

一般に、マージ資源120は、新バージョン内にもはや存在しないか、又は新バージョン内で異なった態様で構造化される各要素になされたカスタマイズをマージするためのソリューション用のカスタマイズ・マッピング情報を格納する。検証手段130は、マージ資源120からカスタマイズ・マッピング情報を受け取り且つ新バージョンに関するカスタマイズ・マッピングの検証を実行する。ソリューション作成手段140は、要素モニタ110によって識別された親要素の子孫(descendent)要素になされたカスタマイズ用のマージ・ソリューションを自動的に生成する。要求作成手段150は、マージ・ソリューションをソリューション作成手段140によって生成することができないか、又は検証手段130によって検証することができない場合に、新バージョン内に相補的要素を有していない各要素になされたカスタマイズ用のマージ・ソリューションのために、開発者からカスタマイズ・マッピング情報入力を要求し且つ受理する。ソリューション消費手段160は、マージ資源120からのカスタマイズ・マッピング情報を読み取り且つ処理することにより、一の要素用のマージ・ソリューションがマッピング情報によって提供されるか否かを決定するとともに、当該要素用のマージ・ソリューションを生成する必要があるか否かを決定する。マージ・インタフェース170は、遙かに少ない開発者入力を必要とするような態様で新バージョンに移行する間に、ソフトウェア成果物の現バージョンになされたカスタマイズの完全に自動化されたマージを可能にする態様で、生成済みのマージ・ソリューションを提供するためのインタフェースを提供する。

0023

図2は、要素モニタ110のサブコンポーネントを一層詳細に示すブロック図である。特に、要素モニタ110は、開発対象となっているソフトウェア成果物の第1バージョン102(例えば、現リリース)及び当該開発によって現に更新される当該ソフトウェア成果物の変更済みの第2バージョン104を、汎用メモリモデル・データ・ストア(以下「メモリ・モデル」又は「データ・ストア」と表記)112に定期的にロードする。後述するように、要素モニタ110は、汎用メモリ・モデル112内に各バージョンのメモリ・モデル表現を生成し、2つの文書の2つのメモリ・モデル表現を比較してそれらの間の相違点を識別し、2つの文書の間の当該識別された相違点に関する情報を含むようにメモリ・モデルを更新する。具体的には、バージョン比較モジュール(以下「比較モジュール」と表記)114は、データ・ストア112にアクセスし、第1バージョン102及び第2バージョン104を比較することにより、第1バージョン102内に存在し且つ第2バージョン104内に相補的要素を有していない親コード要素を識別する。

0024

並列化機構116は、第1バージョン102及び第2バージョン104を並列化し、各バージョンのメモリ・モデル表現を生成し且つこれをメモリ・モデル112内に格納する。各メモリ・モデル表現は、階層的な、ノード・ラベル付きの、ツリー・データ構造の形式を取る。ツリー・データ構造は、1セットのリンク・ノードを有する非同期的連結グラフであり、一般に、正確に1つのルート要素を有するツリー・ベースの意味論的構造を使用する、XML文書を表すために使用される。ツリーは、テキストライン順序付きリストよりも複雑な方法で操作することができる。例えば、実施形態では、文書のツリー構造化メモリ・モデル表現の各々は、多数の順序付き又は順序なしのノードを含むことができる。ツリー内の各ノードは、当該ツリーの下方に、ゼロ又はそれ以上の子ノードを有する(規約により、ツリーは、上方ではなく、下方に伸びる)。子を有するノードは、当該子の親ノード(又は先祖ノード)と呼ばれる。ツリーの最上位ノードは、ルート・ノードと呼ばれる。最上位ノードであるため、ルート・ノードは、親を有していない。図2に示すように、並列化機構116は、第1バージョン102及び第2バージョン104を、第1メモリ・モデル表現(以下「第1モデル」と表記)102a及び第2メモリ・モデル表現(以下「第2モデル」と表記)104aにそれぞれ並列化して、これらのメモリ・モデル表現をメモリ・モデル112内に格納するように動作する。

0025

以下で詳述するように、並列化機構116によって生成されるメモリ・モデル表現は、比較モジュール114によって実行される構文的及び意味論的比較の要件を満たすのに十分に柔軟な、両入力バージョンのXML文書の要素間のマッピング関係を自動的に作成するように動作する。メモリ・モデル112内に維持される表現形式では、表された文書の各XML要素は、当該表現内のツリー・ノードに対応する。かかる各ツリー・ノードが有するコンテキストは、(a)対応するXML要素の属性、(b)対応する要素の全ての子孫XML要素(及びそれらの属性)、(c)当該ノード用の固有(unique)識別子を保持する。この定義によれば、ノード・コンテキストが階層的であることが分かる。一のノードの子は、当該ノードに対応する要素内に保持される要素である。

0026

幾つかのXML文書が有する意味については、一部又は全部の要素の順序が重要でないということを説明する。メモリ・モデル表現は、文書間にわたって対照(counterpart)要素を識別するために、固有識別子概念を使用する。固有識別子は、両バージョン間でソフトウェア成果物コードの要素になされた変更を追跡する場合に、比較モジュール114がアクセスすべき信頼性のあるマーカを提供する。すなわち、固有識別子は、諸要素の内容が、正確な対応する親要素の下で比較されることを保証する。一のノード用の固有識別子は、対応する要素の名前と、当該対応する要素のゼロ又はそれ以上の属性値を含む。各ノード・コンテキストの固有識別子を生成するために、並列化機構116は、要素の1つ以上の属性の値に従って各XML要素に適用される、識別子決定規則リポジトリを使用する。

0027

並列化機構116は、識別子決定規則の容易な追加及び変更をサポートする、固有識別子を生成するための識別子決定規則のリポジトリ用のプラグ可能なフレームワークを提供する。例えば、各ノード用の固有識別子は、各ノードの対応する要素の名前又は属性に依存することなく各ノードを明確に識別することを可能にする、代替的な識別子決定規則の任意の適切な実装に従って、生成することができる。並列化機構116によって実行される固有識別子の生成は、プラグ可能なリポジトリ内の識別子決定規則に依存する。従って、並列化機構116は、ユーザが識別子決定の詳細を制御することにより、特定のアプリケーションの要件を満たすように固有識別子を調整することができる、という点で柔軟性を有する。

0028

実施形態のメモリ・モデルの下では、兄弟(sibling)ノードは、同じ固有識別子を有することができない。この要件を満たすために、並列化機構112は、異なる対応する要素タイプについて異なる複合セットの属性値を有する、固有識別子を生成するように構成することができる。従って、メモリ・モデル表現には、2種類の形式の固有識別子があり得る。第1タイプでは、ノードによって表されるXML要素の名前は、固有識別子を形成するために、属性値なしで使用される。かかる場合、各バージョンのメモリ・モデル表現内には、このタイプの唯1つのノード・コンテキストが生じることが期待される。第2タイプの固有識別子では、ノードによって表されるXML要素の名前及び当該要素の1つ以上の属性の各値は、固有識別子を形成するのに使用される。かかる場合、この要素名を有する2つ以上のノードが各バージョンのメモリ・モデル表現内に保持されることがあり、そして当該固有識別子における1つ以上の選択された属性の値は、各ノードを識別するのに使用される。

0029

一のXML要素用の全ての属性の値又は当該値の組み合わせが、一の親ノード及び当該親の下の各子孫ノードに対し個別に固有である限り、これらの値を当該XML要素に対応するノード用の固有識別子内に含めることは、必要とされない。このため、要素モニタ110は、各メモリ・モデル表現が良好に形成されることを保証することに加え、各文書のメモリ・モデル表現内の各固有識別子が生成される表現内で固有であることを検証する。

0030

複合セットの属性値を有する固有識別子は、文書の意味を考慮に入れることにより、ソフトウェア成果物の2つのバージョン間の相違点を正確に決定するための比較を実行する際に、比較モジュール114が使用すべき柔軟性及び信頼性を有し且つ透明な機構を提供する。メモリ・モデルの下では、第1バージョン102の一のXML文書内の一の要素は、第2バージョン104の一のXML文書内の他の要素の対照要素と見なされる。但し、両要素用の対応するノードが、両バージョンのメモリ・モデル表現内で同じ固有識別子を有することを条件とする。両対照要素が同一であるのは、それらの対応するノードが同じ固有識別子及び複合属性セット内の対応する属性の各々について同等の値を有する場合である。

0031

固有識別子は、ベンダが提供するソフトウェア成果物の両バージョン間で、一貫性を維持しなければならない。しかし、ソフトウェア成果物のバージョンを変更するユーザは、当該ユーザが追加又はカスタマイズする要素について固有識別子を定義することを必要とされない。ユーザが、一の要素に対応するノード用の固有識別子を生成するために使用される当該要素の任意の部分を変更する場合、このことは、あたかも当該要素が新バージョン内で削除され且つ新しい要素として新バージョンに追加されたかのように、マージ・ソリューション・ツール・フレームワーク100内で同じ効果を有するであろう。このことは、表される文書の要素に対応するメモリ・モデル・ノードにおいて、ベンダが当該要素用に提供する任意の更新をマージすることをユーザが望んでいない、という指示を提供するための方法として使用することができる。

0032

比較モジュール114は、比較規則のプラグ可能なリポジトリを使用して、諸文書のメモリ・モデル表現間の比較を実行することにより、それらの間の相違点を決定する。2つの異なるメモリ・モデル表現内の「同じ」ノードを識別するため、これらの比較規則は、比較中のソフトウェア文書の両バージョンの2つの表現内の対照ノード(すなわち、比較中の2つの表現内で同じ固有識別子を有するノード)をリンクし且つ比較中に2つのバージョン内の対照ノードに対応する要素間の相違点に関する情報を生成するように適用される。実施形態では、比較モジュール114は、比較規則のプラグ可能なリポジトリに対し、追加の規則を加える機構を提供する。その結果、比較中のソフトウェア成果物の両バージョンの各文書の諸要素間の相違点に関するより多くの情報を決定することができる。比較モジュール114によって実行される比較は、プラグ可能なリポジトリ内の比較規則に依存する。従って、比較モジュール114は、ユーザが比較の詳細を制御することにより、特定のアプリケーションの要件を満たすように特定の比較中に生成された情報を調整することができるという点で、柔軟性を有する。

0033

図3は、比較モジュール114によって、2つの異なるXMLファイル内にある2つのXML要素を比較し、比較中の両バージョンのメモリ・モデル表現内にある諸要素に対応するノードのコンテキストにアクセスすることにより、それらの相違点を決定するためのプロセス200を示すフローチャートである。両バージョン間のかかる比較を実行するために、比較モジュール114は、第1バージョン内の各要素を第2バージョン内の各要素と比較することにより、2つのバージョン間の最上位要素の全ての可能な追加、削除及び他の変更を調査するように、プロセス200を反復的に実行する。

0034

プロセス200は、判定ブロック210で開始し、そこで比較中の要素を含むソフトウェア成果物のXML文書が、当該要素にとって順序が重要でないことを指定する意味を具備するか否かを決定する。もし、これらのXML文書が、順序が重要であることを指定する意味を具備するのであれば、プロセス200は判定ブロック220に進み、そこで比較中の両バージョン用のメモリ・モデル表現内の要素に対応するノード用のそれぞれの固有識別子が同じであるか否かを決定する。もし、これらの固有識別子が同じでなければ、プロセス200はブロック280に進み、そこで比較中の第1要素が比較中の第2要素を含むバージョン内に存在しないことを記録する。その後、プロセス200は終了する。一方、判定ブロック210で、アプリケーション・パッケージのXML文書が、前記要素にとって順序が重要でないことを指定する意味を具備することを決定すれば、プロセス200は判定ブロック230に進み、そこで比較中の両バージョン用のメモリ・モデル表現内の要素に対応するノード用のそれぞれの固有識別子が同じであるか否かを決定する。

0035

判定ブロック220又は判定ブロック230で、比較中の2つの要素に対応するノード用のそれぞれの固有識別子が同じであることを決定すれば、比較中の2つの要素は対照要素である。その場合、プロセス200はブロック240に進み、そこで前記2つの対照要素の属性(当該要素に対応するノードのメモリ・モデル表現コンテキスト内に提供されるもの)を比較することにより、追加された任意の属性、削除された任意の属性又は変更された値を有する任意の属性を識別する。その後、プロセス200はブロック250に進み、そこで前記2つの対照要素の子要素(当該要素に対応するノードのメモリ・モデル表現コンテキスト内に提供されるもの)のシーケンスを、当該子要素の固有識別子に基づいて比較することにより、前記2つの対照要素の子要素シーケンス内の任意の相違点を識別する。ブロック240及び250における比較中に識別された要素間の相違点に関する情報は、ブロック260で、汎用メモリ・モデル112内に記録される。

0036

判定ブロック230で、比較中の2つの要素に対応するノード用のそれぞれの固有識別子が同じでないことを決定すれば、プロセス200は判定ブロック270に進み、そこで比較中の第1要素に対応するノード用の固有識別子が、比較中の第2要素の兄弟要素に対応するノード用の任意の固有識別子と同じであるか否かを決定する。第1要素に対応するノード用の固有識別子が、第2要素の兄弟要素に対応するノード用の任意の固有識別子と同じでないことを決定すれば、プロセス200はブロック280に進み、そこで比較中の第1要素が比較中の第2要素を含むバージョン内に存在しないことを記録する。一方、判定ブロック230で、第1要素に対応するノード用の固有識別子が、第2要素の兄弟要素に対応するノード用の固有識別子と同じであることを決定すれば、プロセス200はブロック240に進み、ブロック240及び250で、前述のように、第1要素と第2要素のマッチする兄弟要素との間の比較を実行する。ブロック240及び250における比較中に識別された要素間の相違点に関する情報は、ブロック260で、汎用メモリ・モデル112内に記録され、そしてプロセス200が終了する。

0037

図2を再び参照して説明する。データ・ストア112内のコンテキスト・オブジェクト102a及びコンテキスト・オブジェクト104aにアクセスすることにより、第1バージョン102及び第2バージョン104の間の比較を完了する際、比較モジュール114は、比較規則を適用することにより識別された2つの文書間の相違点に関する少なくとも次の情報で、メモリ・モデル内のコンテキスト・オブジェクトを更新する。(1)両バージョン間で削除された諸要素に関する情報、(2)同じXML文書の異なるバージョン内に存在する異なる親要素に関連する諸要素に関する情報、(3)1つの親要素に関連し且つ1つのバージョン内の1つのXML文書内に存在し、しかも異なる親要素に関連し且つ他のバージョン内の異なるXML文書内に存在する諸要素に関する情報、(4)1つの親要素に関連し且つ1つのバージョン内の1つのXML文書内に存在し、しかも同じ親要素に関連し且つ他のバージョン内の異なるXML文書内に存在する諸要素に関する情報、(5)更新済みバージョン内でリネームされた諸要素に関する情報。これらの5つの情報セットは、現バージョン102内に存在する一の要素が新バージョン104内にもはや存在しないか、又は新バージョン104内で異なった態様で構造化される状況を表す。一般に、これらの状況は、コード・リファクタリングに起因する。

0038

図1を再び参照して説明する。マージ資源120は、現バージョン102内に存在し且つ新バージョン104内に相補的要素を有していない各要素に対応する、メモリ・モデル内に格納された記録済みのコンテキスト情報を受け取るとともに、これらの変更済み要素ごとにカスタマイズ・マッピング情報XML要素をインスタンス化及び格納すするように、要素モニタ110のデータ・ストア112と通信する。このカスタマイズ・マッピング情報は、第1バージョンのカスタマイズを新バージョンにマージする場合に、生成されるものである。変更済み要素の各々については、対応するカスタマイズ・マッピング情報XML要素は、次の6つのフィールドを含むようにフォーマットされる。(1)第1バージョン102用のファイル名、(2)第1バージョン102内にある変更済み要素の位置、(3)マージ・ソリューション・キー、(4)第2バージョン104用のファイル名、(5)カスタマイズをマージすべき第2バージョン104内の位置、(6)開発者によって提供される任意の追加的な記述又はコメント(例えば、2つのバージョン間に適用された任意のコード・リファクタリング規則、リファクタリングを実行する特定の理由又は諸要素用のカスタマイズをマージするための特定の命令)。第1バージョン102内の変更済み要素の位置、及びカスタマイズをマージすべき第2バージョン104内の位置の両方に対する値は、XPATHフォーマットで提供される。

0039

以下、図4に示すフローチャートを参照して、マージ・ソリューション・ツール・フレームワーク100の動作中に実行される、マージ・ソリューションを生成するためのプロセス300を説明する。プロセス300は、マージ資源120によってインスタンス化されるカスタマイズ・マッピング情報XML要素ごとに、マージ・ソリューション・ツール・フレームワーク100によって実行される。マージ資源120によってインスタンス化されるマッピング情報要素のうち任意のものについてプロセス300を実行する前に、各要素のために指定されるフィールドは、第1バージョン102用のファイル名、第1バージョン102内の変更済み要素の位置及び開発者によって提供される任意の追加的な記述又はコメントであるに過ぎない。マッピング情報要素ごとに、マージ・ソリューション・キーは、第1バージョン102内のこの要素になされたカスタマイズを第2バージョン104において再適用する必要がないことを指示する「DO_NOT_MERGE」、又は第1バージョン102内のこの要素になされたカスタマイズを第2バージョン104内の新しい位置にマージすべきであることを指示する「MERGE_TO_NEW_INSTANCE」の何れかに設定することができる。

0040

プロセス300のブロック310で、ソリューション消費手段160は、マージ資源120から現マッピング情報要素を読み取る。判定ブロック320で、ソリューション消費手段160は、当該マッピング情報要素を分析することにより、当該要素内に一のカスタマイズ・マージ・ソリューションが提供されているか否かを決定する。すなわち、ソリューション消費手段160は、マージ・ソリューション・キー用のマッピング情報要素フィールド、第2バージョン104用のファイル名、及びカスタマイズをマージすべき第2バージョン内の位置に対する値が指定されているか否かを決定する。もし、如何なるカスタマイズ・マージ・ソリューションも提供されていなければ、ブロック330で、要求作成手段150は、判定ブロック320で分析された諸フィールド用の値を指定することにより、アプリケーション開発者に対する要求を生成して、当該要素用のマージ・ソリューションを提供することを求める。例えば、当該要求は、マージ・ソリューション・ツール・フレームワーク100内で実装され且つ当該ツール・フレームワークが稼働中のコンピュータ・システムを通して開発者がアクセス可能なユーザ・インタフェースを通して、これを提供することができる。また、当該要求は、第1バージョン102用のファイル名、第1バージョン102内の変更済み要素の位置及び開発者によって提供された任意の追加的な記述又はコメントに対する、既に指定済みの値を指示することができる。一般に、当該マッピング情報要素に対応する要素が第1バージョン102内に存在するが、第2バージョン104の開発中に削除されたか、或いは第2バージョン内でカスタマイズ可能でなければ、開発者は、マージ・ソリューション・キーを「DO_NOT_MERGE」と設定し、さもなければ、マージ・ソリューション・キーを「MERGE_TO_NEW_INSTANCE」と設定するであろう。この開発者入力を受け取った後、プロセス300はブロック380に進み、そこでソリューション消費手段160は、マージ・ソリューション情報をマージ資源120内に維持された対応するマッピング情報要素内に格納し、そしてプロセス300が終了する。

0041

もし、判定ブロック320で、ソリューション消費手段160が、一のカスタマイズ・マージ・ソリューションを見つければ、ソリューション消費手段160は、判定ブロック340で、当該マッピング情報要素に対応する要素へのカスタマイズをマージする必要があるか否かを決定する。すなわち、ソリューション消費手段160は、マージ・ソリューション・キーの値を読み取る。もし、このキーが「DO_NOT_MERGE」と設定されていれば、ブロック350で、ソリューション作成手段140は、子孫要素用のマージ・ソリューション・キーを「DO_NOT_MERGE」と指定することにより、現マッピング情報要素に対応する要素の各子孫要素用のカスタマイズ・マージ・ソリューションをマッピング情報フォーマットで生成する。その後、プロセス300はブロック360に進み、そこでソリューション消費手段160は、各子孫要素用の生成済みソリューションをマージ資源120内の対応するマッピング情報要素内に格納する。その後、プロセス300が終了する。

0042

もし、判定ブロック340で、現マッピング情報要素用のマージ・ソリューション・キーが「MERGE_TO_NEW_INSTANCE」と設定されていれば、判定ブロック370で、検証手段130は、第2バージョン104用のファイル名及びカスタマイズをマージすべき第2バージョン内の位置について現マッピング情報要素の諸フィールドによって指定された要素にアクセスし、そして当該ソフトウェア成果物のXML文書用に提供された意味に従って、第2バージョン104内のカスタマイズ・マージ・ソリューションの結果について検証を実行する。もし、判定ブロック370で、当該ソリューションが検証されるならば、プロセス300はブロック380に進み、そこでソリューション消費手段160は、当該ソリューションを、マージ資源120内の対応するマッピング情報要素内に格納する。その後、プロセス300はブロック390に進み、そこでソリューション作成手段140は、現マッピング情報要素に対応する要素の各子要素用のカスタマイズ・マージ・ソリューションをマッピング情報フォーマットで生成する。図4に示すように、プロセス300は、現マッピング情報要素に対応する要素の子要素ごとに、判定ブロック370から再帰的にインスタンス化され且つ実行される。一方、判定ブロック370で、現マッピング情報要素用のカスタマイズ・マージ・ソリューションが検証されなければ、プロセス300はブロック330に進み、そこで要求作成手段150は、アプリケーション開発者に対する要求を生成して、前述の要素用のマージ・ソリューションを提供することを求める。その後、プロセス300が終了する。

0043

図1を再び参照して説明する。一旦システムが、現バージョン102内に存在し且つ新バージョン104内に相補的要素を有していない各要素用のマージ・ソリューションを生成したならば、マージ・ソリューション・ツール・フレームワーク100は、当該マージ・ソリューションのインタフェース・バージョンをマージ・インタフェース170内に生成する。そうするため、ソリューション消費手段160は、マージ資源120にアクセスするとともに、当該マージ・ソリューションをAPI内でラップする。当該APIは、現バージョン102から新バージョン104へのアップグレードが実行される間に、現バージョン102内に存在する要素のうち新バージョン内に相補的要素を有していない要素に対しユーザがなしたカスタマイズをマージするための移行ツールによってアクセスすることができる。マージ・インタフェース170の当該APIは、ユーザによってカスタマイズされた現バージョン102内の一の要素が移行ツールによって識別された場合に、マージ資源120にアクセスして、第2バージョン104用のファイル名及びカスタマイズをマージすべき第2バージョン内の位置を獲得するための MergingInterface.getTargetElement()オブジェクト及び MergingInterface.getTargetFile()オブジェクトを含むことができる。

0044

マージ資源120及びマージ・インタフェース170は、現バージョン102から新バージョン104への移行を実行するソフトウェア・ツールと同時に引き渡され、その後は、新バージョンに移行する際に、現バージョンにユーザがなしたカスタマイズをマージするために当該ユーザによって使用することができる。幾つかの実施形態では、マージ資源120及びマージ・インタフェース170は、ソフトウェア成果物の現バージョン102から新バージョン104に移行するための対応する移行ツール内で実装することができる。マージ資源120及びマージ・インタフェース170は、対応する移行ツール用のソフトウェア・パッケージの一の側面として、或いは対応する移行ツールに組み込むように実装されるソフトウェア・モジュール若しくはコンポーネント(例えば、1つ以上の機能ライブラリ、1つ以上のプラグ・イン又は拡張モジュール、1つ以上の動的リンクライブラリ等)として実装することができる。

0045

前述のように、実施形態は、XML言語文書だけでなく、任意のタイプの構造化文書内のコードから成るソフトウェア成果物になされたカスタマイズを自動的にマージするためのツールを生成するように実装することができる。実施形態では、並列化機構116だけが、XMLの構文を有する文書を扱うという仮定の下で実装されるのに対し、前述の他の手段及びハンドラ・モジュールの各々は、汎用の、階層的メモリ・モデルのコンテキスト・オブジェクトを扱う。従って、代替実施形態では、マージ・ソリューション・ツール・フレームワーク100は、非XML言語を扱うために、例えば、次の2つの方法の何れかで拡張することができる。(1)並列化機構116を、非XML言語を理解するハンドラで置き換える、又は(2)非XML言語をXMLフォーマットに変換するためのプリプロセッサを実装する。さらに、実施形態では、ソフトウェア成果物バージョンの諸文書及び当該バージョンのメモリ・モデル表現の各々は、異なる構文規則を順守することができ、そしてメモリ・モデル表現の諸ノードは、比較中の諸文書及び諸要素の特定のタイプに適切な機構を使用して生成することができる。例えば、ソフトウェア成果物バージョンの諸文書が、HTML言語の構文を有することができるのに対し、諸メモリ・モデル表現は、XML言語の構文を有することができる。

0046

以上では、実施形態を十分に理解することができるように、特定の詳細事項を説明した。しかし、当業者には明らかなように、これらの特定の詳細事項に依拠することなく、他の実施形態を実施することが可能であり、その場合において構造的、論理的及び電気的変更を施すことができる。

0047

実施形態は、ハードウェア、ソフトウェア又はハードウェア及びソフトウェアの組み合わせの形態で実現することができる。実施形態は、1つ以上のプログラム・モジュール及びデータ・ストレージ・ユニットを使用して実現することができる。実施形態は、1つのコンピュータ・システム内で集中的に実現するか、又は異なる要素が相互接続された幾つかのコンピュータ・システム間に散在する場合は、分散的に実現することができる。任意の種類のコンピュータ・システム、又は本明細書に開示した方法を実施するのに適した他の装置を使用することができる。ハードウェア及びソフトウェアの代表的な組み合わせは、汎用コンピュータ・システムと、当該コンピュータ・システムにロードされ且つそこで実行される場合、本明細書に開示した方法を実施するように当該コンピュータ・システムを制御するコンピュータ・プログラムの組み合わせとすることができる。

0048

また、実施形態は、本明細書に開示した方法の実施を可能にする全ての機能を具備する、コンピュータ・プログラム内に埋め込むことができる。かかるコンピュータ・プログラムは、コンピュータ・システムにロードされると、これらの方法を実施することができる。本明細書において、コンピュータ・プログラム手段又はコンピュータ・プログラムは、任意の言語、コード又は表記に従った1セットの命令の任意の表現であって、情報処理能力を有するシステムに対し、特定の機能を、直接的に、或いは(a)他の言語、コード又は表記への変換、及び(b)他の資料形式における再生の一方又は両方の後に、実行させるように意図されたものを意味する。

0049

実施形態を実装することができるコンピュータ・システムは、特に、1つ以上のコンピュータ及びコンピュータ可読媒体上の少なくとも1つのコンピュータ・プログラムを含み、当該コンピュータ・プログラムは、コンピュータ・システムが前記コンピュータ可読媒体からデータ、命令、メッセージ又はメッセージ・パケット及び他のコンピュータ可読情報を読み取ることを可能にする。コンピュータ可読媒体は、ROM、フラッシュ・メモリ、ディスクドライブ・メモリ、CD−ROM及び他の永続ストレージのような不揮発性メモリを含むことができる。さらに、コンピュータ可読媒体は、RAM、バッファキャッシュ・メモリ及びネットワーク回路のような揮発性ストレージを含むことができる。さらに、コンピュータ可読媒体は、有線ネットワーク又は無線ネットワークを含むネットワーク・リンク又はネットワーク・インタフェースのような過渡状態媒体内にコンピュータ読み取り可能な情報を含むことができ、コンピュータ・システムがかかるコンピュータ読み取り可能な情報を読み取ることを可能にする。

0050

図5は、実施形態を実装するために使用することができる、コンピュータ・システム500のブロック図である。コンピュータ・システム500は、プロセッサ504のような1つ以上のプロセッサを含む。プロセッサ504は、通信インフラストラクチャ502(例えば、通信バスクロスオーバー・バー又はネットワーク)に接続される。種々のソフトウェア実施形態は、このコンピュータ・システム500の観点から説明される。この説明を十分に理解すれば、他のコンピュータ・システム又はコンピュータ・アーキテクチャを使用する場合、本発明をどのように実装するかということが明らかになるであろう。

0051

コンピュータ・システム500は、通信インフラストラクチャ502(又は図示されていないフレーム・バッファ)からのグラフィックス、テキスト及び他のデータを、表示ユニット510に転送する表示インタフェース508を含むことができる。また、コンピュータ・システム500は、ランダム・アクセス・メモリ(RAM)形式の主メモリ506及び2次メモリ512を含むことができる。2次メモリ512は、例えば、ハード・ディスク・ドライブ514及び(フレキシブル・ディスク・ドライブ、磁気テープ・ドライブ、光ディスク・ドライブ等を表す)取り外し可能なストレージ・ドライブ516を含むことができる。取り外し可能なストレージ・ドライブ516は、当業者には周知の態様で、取り外し可能なストレージ・ユニット518を対象とする読み取り及び書き込みを行う。取り外し可能なストレージ・ユニット518は、例えば、フレキシブル・ディスク、磁気テープ、光ディスク等を表し、その各々を対象とする読み取り及び書き込みは、取り外し可能なストレージ・ドライブ516によって行われる。取り外し可能なストレージ・ユニット518は、コンピュータ・ソフトウェア及びデータを格納したコンピュータ使用可能なストレージ媒体を含む。

0052

2次メモリ512は、コンピュータ・プログラム又は他の諸命令をコンピュータ・システムにロードすることを可能にするための他の同様の手段を含むことができる。かかる手段は、例えば、取り外し可能なストレージ・ユニット522及びインタフェース520を含むことができる。これらの例は、プログラム・カートリッジ及びカートリッジ・インタフェース(例えば、ビデオゲーム装置に見られるようなもの)、取り外し可能なメモリ・チップ(例えば、EPROM又はPROM)及び関連するソケット、並びにソフトウェア及びデータを取り外し可能なストレージ・ユニット522からコンピュータ・システム500に転送することを可能にする他の取り外し可能なストレージ・ユニット522及びインタフェース520を含むことができる。

0053

また、コンピュータ・システム500は、通信インタフェース524を含むことができる。通信インタフェース524は、ソフトウェア及びデータをコンピュータ・システムと外部装置の間で転送することを可能にする。通信インタフェース524の例は、モデム、ネットワーク・インタフェース(例えば、イーサネットカード)、通信ポートPCMCIスロット及びカード等を含むことができる。通信インタフェース524を介して転送されるソフトウェア及びデータは、例えば、通信インタフェース524によって受信することができる電子電磁気、光、又は他の信号の形式とすることができる。これらの信号は、通信パス(すなわち、チャネル)526を介して、通信インタフェース524に提供される。チャネル526は、諸信号を担持し、ケーブル光ファイバ電話線携帯電話リンク、RFリンク及び他の通信チャネルを使用して実装することができる。

0054

本明細書において、「コンピュータ・プログラム媒体」、「コンピュータ使用可能な媒体」及び「コンピュータ可読媒体」という用語は、主メモリ506及び2次メモリ512、取り外し可能なストレージ・ドライブ516、ハード・ディスク・ドライブ514内に装着されたハード・ディスク及び諸信号のような媒体を包括的に意味する。これらのコンピュータ・プログラムは、ソフトウェアをコンピュータ・システムに提供するための手段である。

0055

コンピュータ・プログラムは、コンピュータ制御論理とも呼ばれ、主メモリ506及び2次メモリ512の一方又は両方に格納される。また、コンピュータ・プログラムは、通信インタフェース524を介して受け取られることもある。かかるコンピュータ・プログラムは、実行されるとき、コンピュータ・システムが、前述の実施形態の諸機能を実行することを可能にする。特に、コンピュータ・プログラムは、実行されるとき、プロセッサ504がコンピュータ・システム500の諸機能を実行することを可能にする。従って、かかるコンピュータ・プログラムは、コンピュータ・システムのコントローラを表す。

0056

以上では実施形態を詳述したが、本発明に関する記述は、網羅的であること又は開示された実施形態に本発明を制限することを意図するものではない。請求項の記載によって定義される本発明の趣旨及び範囲から逸脱することなく、種々の変更、置換及び修正をなし得ることは明らかであろう。実施形態に対する変形は、特定の各アプリケーションにとって望ましい任意の組み合わせにおいて実現することができる。従って、本明細書に開示した実施形態の特定の制限又は拡張が、特定のアプリケーションにとって特定の利点を有することがあるとしても、これを全てのアプリケーションについて使用する必要はない。さらに、実施形態に関連して説明した1つ以上の概念を含む、方法、システム及び装置において、全ての制限事項を実装する必要があるとは限らない。

0057

本明細書に提示した実施形態は、本発明の原理及び実際的な応用を最もよく説明し、当業者が本発明を理解することを可能にするために、選択され説明されたものである。当業者にとって、実施形態に対する多くの修正及び変形が明らかであろう。かかる修正及び変形は、請求項の記載によって定義される本発明の範囲内に属することが意図される。

0058

102・・・・第1バージョン
102a・・・第1モデル
104・・・・第2バージョン
104a・・・第2モデル
110・・・・要素モニタ
112・・・・メモリ・モデル
114・・・・比較モジュール
116・・・・並列化機構
120・・・・マージ資源
130・・・・検証手段
140・・・・ソリューション作成手段
150・・・・要求作成手段
160・・・・ソリューション消費手段
170・・・・マージ・インタフェース

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ