IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ エスアーペー エスエーの特許一覧

特開2023-159020コード変更を識別し特性化するシステム
<>
  • 特開-コード変更を識別し特性化するシステム 図1
  • 特開-コード変更を識別し特性化するシステム 図2
  • 特開-コード変更を識別し特性化するシステム 図3A
  • 特開-コード変更を識別し特性化するシステム 図3B
  • 特開-コード変更を識別し特性化するシステム 図4A
  • 特開-コード変更を識別し特性化するシステム 図4B
  • 特開-コード変更を識別し特性化するシステム 図5
  • 特開-コード変更を識別し特性化するシステム 図6
  • 特開-コード変更を識別し特性化するシステム 図7
  • 特開-コード変更を識別し特性化するシステム 図8
  • 特開-コード変更を識別し特性化するシステム 図9
  • 特開-コード変更を識別し特性化するシステム 図10
  • 特開-コード変更を識別し特性化するシステム 図11
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023159020
(43)【公開日】2023-10-31
(54)【発明の名称】コード変更を識別し特性化するシステム
(51)【国際特許分類】
   G06F 8/65 20180101AFI20231024BHJP
【FI】
G06F8/65
【審査請求】未請求
【請求項の数】20
【出願形態】OL
【外国語出願】
(21)【出願番号】P 2022199441
(22)【出願日】2022-12-14
(31)【優先権主張番号】17/724,230
(32)【優先日】2022-04-19
(33)【優先権主張国・地域又は機関】US
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.JAVASCRIPT
2.JAVA
(71)【出願人】
【識別番号】300015447
【氏名又は名称】エスアーペー エスエー
【住所又は居所原語表記】Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(72)【発明者】
【氏名】セバスチアン・ラヴォワニャ
【テーマコード(参考)】
5B376
【Fターム(参考)】
5B376AA32
5B376AA33
(57)【要約】
【課題】ソフトウェアアプリケーションコードの変更の効率的な特性化を行うシステムおよび方法を提供すること。
【解決手段】システムおよび方法は、第1のコードアーチファクトおよび第2のコードアーチファクトの決定と、第1のコードアーチファクトに基づいた第1の複数のキー/値ペアおよび第2のコードアーチファクトに基づいた第2の複数のキー/値ペアの生成と、第1の複数のキー/値ペアと第2の複数のキー/値ペアとの間の複数の変更の識別であって、複数の変更が第3の複数のキー/値ペアによって表される、識別と、複数のルールのそれぞれについて、第3の複数のキー/値ペアがルールに関連付けられる少なくとも1つのキー/値ペアを含むかどうかの決定、およびそうである場合、ルールを少なくとも1つのキー/値ペアのそれぞれに適用して、少なくとも1つのキー/値ペアのそれぞれに関連付けられる解析出力の決定と、解析出力に基づいた可視化の生成とを含む。
【選択図】図1
【特許請求の範囲】
【請求項1】
システムであって、
プロセッサが実行可能なプログラムコードを記憶するメモリと、
前記プロセッサが実行可能なプログラムコードを実行して、前記システムに
第1のアプリケーションの第1のコードアーチファクトおよび前記第1のアプリケーションの第2のコードアーチファクトを決定すること、
前記第1のコードアーチファクトに基づいて第1の複数のキー/値ペア、および前記第2のコードアーチファクトに基づいて第2の複数のキー/値ペアを生成すること、
前記第1の複数のキー/値ペアと前記第2の複数のキー/値ペアとの間の複数の変更を識別することであって、前記複数の変更が、第3の複数のキー/値ペアを含む、識別すること、
前記第1のアプリケーションに関連付けられる複数のルールを決定すること、
前記複数のルールのそれぞれについて、
前記第3の複数のキー/値ペアが前記ルールに関連付けられる少なくとも1つのキー/値ペアを含むかどうかを決定し、
前記第3の複数のキー/値ペアが前記ルールに関連付けられる少なくとも1つのキー/値ペアを含む場合、前記ルールを前記少なくとも1つのキー/値ペアのそれぞれに適用して、前記少なくとも1つのキー/値ペアのそれぞれに関連付けられる解析出力を決定すること、ならびに
前記解析出力に基づいて、可視化を生成すること
を行わせる処理装置と
を備える、システム。
【請求項2】
前記第3の複数のキー/値ペアが、追加されたキーに関連付けられる第4の複数のキー/値ペアと、削除されたキーに関連付けられる第5の複数のキー/値ペアと、更新されたキーに関連付けられる第6の複数のキー/値ペアとを含む、請求項1に記載のシステム。
【請求項3】
前記可視化の生成が、
第1の数の追加されたキー、第2の数の削除されたキー、および第3の数の更新されたキーの決定と、
前記第1の数、前記第2の数、および前記第3の数を含む前記可視化の生成と
を含む、請求項2に記載のシステム。
【請求項4】
前記可視化の生成が、
前記追加されたキー、前記削除されたキー、および前記更新されたキーのそれぞれに関連付けられるスコアの決定と、
前記決定されたスコアに基づいた関数スコアの決定と、
前記関数スコアを含む前記可視化の生成と
を含む、請求項3に記載のシステム。
【請求項5】
第1のキー/値ペアに関連付けられる第1の解析出力が、前記第1のアーチファクトにおける前記第1のキー/値ペアの前記キーに関連付けられるオブジェクトが前記第2のアーチファクトに存在しないというテキストメッセージを含み、
第2のキー/値ペアに関連付けられる第2の解析出力が、前記第1のアーチファクトにおける前記第2のキー/値ペアの前記キーに関連付けられるプロパティの値が前記第2のアーチファクトにおいて変更されているという第2のテキストメッセージを含み、
前記可視化が、前記テキストメッセージおよび前記第2のテキストメッセージを含む、
請求項1に記載のシステム。
【請求項6】
前記第1の複数のキー/値ペアの生成が、
前記第1のアーチファクトのコードの1番目の行が、第1のオブジェクト名に関連付けられるオブジェクトを含むことの決定と、
前記第1のオブジェクト名に基づいた第1のキー/値ペアの第1のキーの決定と、
前記第1のオブジェクト名に基づいた前記第1のキー/値ペアの第1の値の決定と
を含む、請求項1に記載のシステム。
【請求項7】
前記第1の複数のキー/値ペアの生成が、
前記第1のアーチファクトのコードの2番目の行が、前記第1のオブジェクト名に関連付けられる前記オブジェクトのプロパティを含むことの決定と、
前記第1のオブジェクト名および前記プロパティの名前に基づいた第2のキー/値ペアの第2のキーの決定と、
コードの前記2番目の行における前記プロパティに関連付けられる値に基づいた前記第2のキー/値ペアの第2の値の決定と
を含む、請求項6に記載のシステム。
【請求項8】
第1のコードアーチファクトおよび第2のコードアーチファクトを決定するステップと、
前記第1のコードアーチファクトに基づいて第1の複数のキー/値ペア、および前記第2のコードアーチファクトに基づいて第2の複数のキー/値ペアを生成するステップと、
前記第1の複数のキー/値ペアと前記第2の複数のキー/値ペアとの間の複数の変更を識別するステップであって、前記複数の変更が、第3の複数のキー/値ペアによって表される、ステップと、
複数のルールのそれぞれについて、
前記第3の複数のキー/値ペアが前記ルールに関連付けられる少なくとも1つのキー/値ペアを含むかどうかを決定し、
前記第3の複数のキー/値ペアが前記ルールに関連付けられる少なくとも1つのキー/値ペアを含む場合、前記ルールを前記少なくとも1つのキー/値ペアのそれぞれに適用して、前記少なくとも1つのキー/値ペアのそれぞれに関連付けられる解析出力を決定するステップと、
前記解析出力に基づいて、可視化を生成するステップと
を含む、コンピュータ実装方法。
【請求項9】
前記第3の複数のキー/値ペアが、追加されたキーに関連付けられる第4の複数のキー/値ペアと、削除されたキーに関連付けられる第5の複数のキー/値ペアと、更新されたキーに関連付けられる第6の複数のキー/値ペアとを含む、請求項8に記載の方法。
【請求項10】
前記可視化を生成するステップが、
第1の数の追加されたキー、第2の数の削除されたキー、および第3の数の更新されたキーを決定するステップと、
前記第1の数、前記第2の数、および前記第3の数を含む前記可視化を生成するステップと
を含む、請求項9に記載の方法。
【請求項11】
前記可視化を生成するステップが、
前記追加されたキー、前記削除されたキー、および前記更新されたキーのそれぞれに関連付けられるスコアを決定するステップと、
前記決定されたスコアに基づいて関数スコアを決定するステップと、
前記関数スコアを含む前記可視化を生成するステップと
を含む、請求項10に記載の方法。
【請求項12】
第1のキー/値ペアに関連付けられる第1の解析出力が、前記第1のアーチファクトにおける前記第1のキー/値ペアの前記キーに関連付けられるオブジェクトが前記第2のアーチファクトに存在しないというテキストメッセージを含み、
第2のキー/値ペアに関連付けられる第2の解析出力が、前記第1のアーチファクトにおける前記第2のキー/値ペアの前記キーに関連付けられるプロパティの値が前記第2のアーチファクトにおいて変更されているという第2のテキストメッセージを含み、
前記可視化が、前記テキストメッセージおよび前記第2のテキストメッセージを含む、
請求項8に記載の方法。
【請求項13】
前記第1の複数のキー/値ペアを生成するステップが、
前記第1のアーチファクトのコードの1番目の行が、第1のオブジェクト名に関連付けられるオブジェクトを含むことを決定するステップと、
前記第1のオブジェクト名に基づいて第1のキー/値ペアの第1のキーを決定するステップと、
前記第1のオブジェクト名に基づいて前記第1のキー/値ペアの第1の値を決定するステップと
を含む、請求項8に記載の方法。
【請求項14】
前記第1の複数のキー/値ペアを生成するステップが、
前記第1のアーチファクトのコードの2番目の行が、前記第1のオブジェクト名に関連付けられる前記オブジェクトのプロパティを含むことを決定するステップと、
前記第1のオブジェクト名および前記プロパティの名前に基づいて第2のキー/値ペアの第2のキーを決定するステップと、
コードの前記2番目の行における前記プロパティに関連付けられる値に基づいて前記第2のキー/値ペアの第2の値を決定するステップと
を含む、請求項13に記載の方法。
【請求項15】
コンピューティングシステムの処理装置によって実行可能なプログラムコードを記憶する非一時的コンピュータ可読媒体であって、前記プログラムコードが、前記コンピューティングシステムに、
第1のアプリケーションの第1のコードアーチファクトおよび前記第1のアプリケーションの第2のコードアーチファクトを決定すること、
前記第1のコードアーチファクトに基づいて第1の複数のキー/値ペア、および前記第2のコードアーチファクトに基づいて第2の複数のキー/値ペアを生成すること、
前記第1の複数のキー/値ペアと前記第2の複数のキー/値ペアとの間の複数の変更を識別することであって、前記複数の変更が、第3の複数のキー/値ペアを含む、識別すること、
前記第1のアプリケーションに関連付けられる複数のルールを決定すること、
前記複数のルールのそれぞれについて、
前記第3の複数のキー/値ペアが前記ルールに関連付けられる少なくとも1つのキー/値ペアを含むかどうかを決定し、
前記第3の複数のキー/値ペアが前記ルールに関連付けられる少なくとも1つのキー/値ペアを含む場合、前記ルールを前記少なくとも1つのキー/値ペアのそれぞれに適用して、前記少なくとも1つのキー/値ペアのそれぞれに関連付けられる解析出力を決定すること、ならびに
前記解析出力に基づいて、可視化を生成すること
を行わせる、
非一時的コンピュータ可読媒体。
【請求項16】
第1のキー/値ペアに関連付けられる第1の解析出力が、前記第1のアーチファクトにおける前記第1のキー/値ペアの前記キーに関連付けられるオブジェクトが前記第2のアーチファクトに存在しないというテキストメッセージを含み、
第2のキー/値ペアに関連付けられる第2の解析出力が、前記第1のアーチファクトにおける前記第2のキー/値ペアの前記キーに関連付けられるプロパティの値が前記第2のアーチファクトにおいて変更されているという第2のテキストメッセージを含み、
前記可視化が、前記テキストメッセージおよび前記第2のテキストメッセージを含む、
請求項15に記載の媒体。
【請求項17】
前記第1の複数のキー/値ペアの生成が、
前記第1のアーチファクトのコードの1番目の行が、第1のオブジェクト名に関連付けられるオブジェクトを含むことの決定と、
前記第1のオブジェクト名に基づいた第1のキー/値ペアの第1のキーの決定と、
前記第1のオブジェクト名に基づいた前記第1のキー/値ペアの第1の値の決定と
を含む、請求項15に記載の媒体。
【請求項18】
前記第1の複数のキー/値ペアの生成が、
前記第1のアーチファクトのコードの2番目の行が、前記第1のオブジェクト名に関連付けられる前記オブジェクトのプロパティを含むことの決定と、
前記第1のオブジェクト名および前記プロパティの名前に基づいた第2のキー/値ペアの第2のキーの決定と、
コードの前記2番目の行における前記プロパティに関連付けられる値に基づいた前記第2のキー/値ペアの第2の値の決定と
を含む、請求項17に記載の媒体。
【請求項19】
前記第3の複数のキー/値ペアが、追加されたキーに関連付けられる第4の複数のキー/値ペアと、削除されたキーに関連付けられる第5の複数のキー/値ペアと、更新されたキーに関連付けられる第6の複数のキー/値ペアとを含み、
前記可視化の生成が、
第1の数の追加されたキー、第2の数の削除されたキー、および第3の数の更新されたキーの決定と、
前記第1の数、前記第2の数、および前記第3の数を含む前記可視化の生成と
を含む、請求項15に記載の媒体。
【請求項20】
前記可視化の生成が、
前記追加されたキー、前記削除されたキー、および前記更新されたキーのそれぞれに関連付けられるスコアの決定と、
前記決定されたスコアに基づいた関数スコアの決定と、
前記関数スコアを含む前記可視化の生成と
を含む、請求項19に記載の媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、ソフトウェアアプリケーションコードの変更の効率的な特性化に関する。
【背景技術】
【0002】
オンプレミスまたはクラウドで実行されるソフトウェアアプリケーションは、多くのタスクの効率を大きく向上させている。最近のソフトウェア開発サイクルの結果、そのようなソフトウェアアプリケーションの新しいバージョンが定期的にリリースされている。これらの新しいバージョンは、たとえば、機能を追加する、プログラミングエラー(すなわち、バグ)に対処する、または機能を廃止予定にすることがある。そのため、通常、ソフトウェアアプリケーションの最新のバージョンの使用は、ユーザにとって望ましい。
【0003】
しかしながら、ユーザは、自分のソフトウェアアプリケーションを最新のバージョンにアップグレードすることを躊躇する場合がある。アップグレードには、システムのダウンタイム、ならびに(たとえば、ユーザが新しい機能の操作を習得する間)、一時的な効率の低下を伴うことがある。したがって、ユーザは、そのようなアップグレード(たとえば、新しいバージョンによって提供される追加の機能)の期待される恩恵がわずかである場合、ソフトウェアアプリケーションを新しいバージョンにアップグレードしたがらない場合がある。
【0004】
また、ユーザは、ソフトウェアアプリケーションを新しいバージョンにアップグレードすると、ソフトウェアアプリケーションによって作成された、または別の形でソフトウェアアプリケーションに依存している、既存のワークフローが壊れる可能性があることを懸念する場合もある。この懸念は、最近の分散型コンピューティングランドスケープが統合される性質であることに起因して、ますます広がっている。たとえば、ソフトウェアアプリケーションの入力パラメータに変更をもたらすアップグレードは、アップグレードされたソフトウェアアプリケーションへの入力を可能にするために、別のアプリケーションに依存しているシステムを無効にする場合がある。
【0005】
上記に対処するための従来の技法は、ソフトウェアアプリケーションの2つのバージョンを比較するためのアプリケーション固有のアルゴリズムを含む。そのようなアルゴリズムは、特定のソフトウェアアプリケーションの2つのバージョンの様々なオブジェクトにおける差異を識別する。次いで、各変更されたオブジェクトについて、オブジェクト固有のアルゴリズムが適用されて、オブジェクトへの変更の関数記述を決定する。そのような手法では、アプリケーション固有およびオブジェクト固有の別個の比較アルゴリズムのコーディングが必要であるだけでなく、新規プロパティがオブジェクトに追加されたとき、アルゴリズムは、再コーディングもされなければならない。その上、品質を確保するためには、各アルゴリズムを、一定の期間にわたって、ユニットテストし保守すべきである。そのため、これらの技法は、それほど効率的でなく、スケーラブルでない。
【発明の概要】
【発明が解決しようとする課題】
【0006】
ソフトウェアアプリケーションコードの変更の効率的な特性化を行うシステムが望ましい。
【課題を解決するための手段】
【0007】
本開示の実施形態は、システムを提供する。本システムは、
プロセッサが実行可能なプログラムコードを記憶するメモリと、
プロセッサが実行可能なプログラムコードを実行して、システムに
第1のアプリケーションの第1のコードアーチファクトおよび第1のアプリケーションの第2のコードアーチファクトを決定すること、
第1のコードアーチファクトに基づいて第1の複数のキー/値ペア、および第2のコードアーチファクトに基づいて第2の複数のキー/値ペアを生成すること、
第1の複数のキー/値ペアと第2の複数のキー/値ペアとの間の複数の変更を識別することであって、複数の変更が、第3の複数のキー/値ペアを含む、識別すること、
第1のアプリケーションに関連付けられる複数のルールを決定すること、
複数のルールのそれぞれについて、
第3の複数のキー/値ペアがルールに関連付けられる少なくとも1つのキー/値ペアを含むかどうかを決定し、
第3の複数のキー/値ペアがルールに関連付けられる少なくとも1つのキー/値ペアを含む場合、ルールを少なくとも1つのキー/値ペアのそれぞれに適用して、少なくとも1つのキー/値ペアのそれぞれに関連付けられる解析出力を決定すること、ならびに
解析出力に基づいて、可視化を生成すること
を行わせる処理装置と
を備える。
【図面の簡単な説明】
【0008】
図1】いくつかの実施形態によるシステムアーキテクチャのブロック図である。
図2】いくつかの実施形態によるコード変更を識別し特性化する方法のフロー図である。
図3A】いくつかの実施形態によるプログラムコードの一部分を示す図である。
図3B】いくつかの実施形態による図3Aのプログラムコードに基づいて生成されたキー/値ペア(key, value pairs)を示す図である。
図4A】いくつかの実施形態によるプログラムコードの一部分を示す図である。
図4B】いくつかの実施形態による図4Aのプログラムコードに基づいて生成されたキー/値ペアを示す図である。
図5】いくつかの実施形態によるプログラムコードに基づいてキー/値ペアを生成する方法のフロー図である。
図6】いくつかの実施形態によるキー/値ペアに基づいてコード変更を識別する方法のフロー図である。
図7】いくつかの実施形態によるコード変更を表すキー/値ペアのリストを示す図である。
図8】いくつかの実施形態によるルールスキーマを表す図である。
図9】いくつかの実施形態による解析オブジェクトスキーマを表す図である。
図10】いくつかの実施形態によるコード変更の特性化を表すユーザインターフェースの図である。
図11】いくつかの実施形態によるシステムアーキテクチャを実装するコンピューティングシステムのブロック図である。
【発明を実施するための形態】
【0009】
次の説明は、あらゆる当業者が、説明した実施形態を作成し使用できるようにするために提供される。しかしながら、様々な変更形態については、当業者にはなおも容易にわかるであろう。
【0010】
いくつかの実施形態は、プログラムコードの第1のバージョンを第2のバージョンと比較し、比較の結果に対応する関数コンテキスト(functional context)を決定するカスタムルールを組み込むための汎用アルゴリズムを提供する。次いで、これらの関数コンテキスト、およびいくつかの実施形態においては、対応するスコアは、ユーザに提示されて、第1のバージョンから第2のバージョンにアップグレードすべきか否かを決定する際のユーザの助けになり得る。汎用アルゴリズムは、比較されるコードの型に関係なく同じままであるので、新しいコード型または変更されたコード型にこのアルゴリズムを適用しても、汎用アルゴリズムに関する開発リソースは消費されない。むしろ、汎用アルゴリズムによって検出される特定のプロパティに対する変更を解析するためだけに、新しいルールが必要であり得る。
【0011】
いくつかの実施形態によれば、最初に、2つのコードアーチファクトが、比較される。コードアーチファクトは、当技術分野で知られているように、構築方法の副産物を含み得る。コードアーチファクトとしては、限定するものではないが、ソースコード、コンパイル済みコード、依存関係、バイナリ、またはリソースを挙げることができる。2つのコードアーチファクトを比較するために、諸実施形態は、各コードアーチファクトに関連付けられるシグネチャを生成する。後述するように、シグネチャは、アーチファクトにおけるコードの各行に対応するキー/値ペアのセットを含むことができる。
【0012】
各アーチファクトのキー/値ペアのセットを比較して、キー/値ペアの3つのサブセット、すなわち、新規、削除、および更新を決定する。次いで、キー/値ペアのサブセットにルールを適用して、対応するコード変更の関数コンテキストおよび/または増分関数スコア(functional score)を決定する。これに関しては、各キー/値ペアは、キー/値ペアによって表されるコードに関する情報を含む。詳細に後述するように、ルールが、この情報に基づいて、およびキー/値ペアが属しているサブセット(すなわち、新規、削除、または更新)に基づいて、関数コンテキスト(および/または関数スコア)を決定し得る。
【0013】
図1は、いくつかの実施形態によるアーキテクチャ100のブロック図である。アーキテクチャ100の例示の構成要素は、既知の、または既知になるコンピューティングハードウェアおよび/またはソフトウェアの任意の適切な組合せを使用して実装され得る。そのような組合せとしては、1つまたは複数のプログラマブルプロセッサ(マイクロプロセッサ、中央処理装置、マイクロプロセッサコア、実行スレッド)、1つまたは複数の非一時的電子ストレージ媒体、およびプロセッサが実行可能なプログラムコードを挙げることができる。いくつかの実施形態においては、アーキテクチャ100の2つ以上の構成要素が、単一のコンピューティングデバイスによって実装され、および/またはアーキテクチャ100の2つ以上の構成要素が、同一場所に配置される。アーキテクチャ100の1つまたは複数の構成要素は、クラウドベースのリソース、ならびに/または需要、ニーズ、価格、および/もしくは任意の他のメトリックに従って弾力的にコンピューティングリソースを分配する他のシステムを使用して実装されてもよい。
【0014】
アーキテクチャ100の構成要素は、アーチファクトA 110とアーチファクトB 115との差異を識別し特性化するように動作し得る。アーチファクトA 110およびアーチファクトB 115はそれぞれ、既知の、または既知になる任意のオブジェクト指向型プログラミング言語に準拠するコードの一部分を含むことができる。そのようなコードは、たとえば、JavaScript、C#、Java、またはC++に準拠し得る。アーチファクトA 110およびアーチファクトB 115は、同じソフトウェアアプリケーションの異なるバージョンを含むことができ、そのため、各アーチファクトは、様々なモジュールデータ型列挙などを含むことができる。次の例のために、アーチファクトBは、アーチファクトAよりも最近のバージョンであると仮定する。
【0015】
シグネチャジェネレータ120が、アーチファクトA 110に基づいてシグネチャAを生成し、アーチファクトB 115に基づいてシグネチャBを生成する。各シグネチャは、キー/値ペアのリストからなる。概して、キーは、アーチファクトの構造を表し、値は、各アーチファクトに関連付けられるプロパティ値を表す。シグネチャを生成するための実装形態については、詳細に後述する。
【0016】
シグネチャコンパレータ130が、シグネチャAをシグネチャBと比較する。比較の結果、リストが得られ、このリストは、シグネチャBに存在しシグネチャAに存在しないそれらのキー(すなわち、「新規(new)」キー)を識別し、シグネチャAに存在しシグネチャBに存在しないそれらのキー(すなわち、「削除(removed)」キー)を識別し、シグネチャAとシグネチャBの両方に存在するがその中の異なる値に関連付けられるそれらのキー(すなわち、「更新(updated)」キー)を識別する。識別されたキー(およびそれらの関連付けられた値)は、図1における変更135と示されている、それぞれのNewリスト、Addedリスト、およびUpdatedリストに含められる。
【0017】
変更アナライザ140が、解析ルール150に基づいて変更135を解析する。詳細に後述するように、解析ルール150はそれぞれ、解析ルールを適用すべき変更135のキーを識別するのに使用される情報を含む。また、解析ルール150はそれぞれ、解析ルールが適用されるキーに関連付けられる解析オブジェクト155を返す関数も含む。いくつかの実施形態によれば、各解析オブジェクト155は、変更されたコードエンティティの型を識別し、変更されたコードエンティティが「新規」であるのか、「削除」であるのか、または「更新」であるのかを識別し、ユーザが理解できる言語で変更を説明するメッセージを識別する。
【0018】
いくつかの実施形態においては、解析オブジェクト155はまた、変更は互換性がある(たとえば、期待されている)か、互換性がない(たとえば、期待されていない)か、または可能性として問題をはらんでいる(すなわち、チェックすべきである)かを示すために、警告レベルプロパティも含み得る。また、または代替として、解析オブジェクト155は、関連付けられた変更の重要度レベル(たとえば、非常に重要、重要、中、低、非常に低)を指定してもよい。
【0019】
また、変更に関連付けられる解析オブジェクト155は、変更の望ましさを示すことができる増分スコアも含む。いくつかの実施形態においては、すべての解析オブジェクト155のすべての増分スコアを加算して、アーチファクトA 110とアーチファクトB 115との比較に関連付けられる関数スコアを決定する。関数スコアは、いくつかの実施形態においては、0と100との間の値に限定され得る。関数スコアは、ユーザに、アーチファクトA 110からアーチファクトB 115へのアップグレードが望ましい程度を示すことができる。
【0020】
解析オブジェクト155は、いくつかの実施形態により、可視化ジェネレータ160によって消費され得る。可視化ジェネレータ160は、たとえば、解析オブジェクト155において指定される変更のハイパーテキストマークアップ言語可視化170を生成することができる。そのような可視化の例については、後述する。
【0021】
図2は、いくつかの実施形態によるコード変更を識別し特性化する方法のフロー図である。方法200は、ハードウェアとソフトウェアとの任意の適切な組合せを用いて行うことができる。この方法を具現化するソフトウェアプログラムコードは、固定ディスク、揮発性または不揮発性のランダムアクセスメモリ、DVD、フラッシュドライブ、または磁気テープを含む任意の非一時的有形媒体によって記憶され、限定するものではないが、プロセッサ、プロセッサコア、およびプロセッサスレッドを含む任意の数の処理装置によって実行され得る。そのようなプロセッサ、プロセッサコア、およびプロセッサスレッドは、クラウドベースのアーキテクチャにおいてプロビジョニングされる仮想マシンによって実装されてもよい。諸実施形態は、後述する例に限定するものではない。
【0022】
方法200は、第1のソフトウェアバージョンから第2のソフトウェアバージョンへの提案されたまたは潜在的な更新に関する情報を求めるユーザ要求に応答して開始され得る。いくつかの実施形態においては、方法200は、限定するものではないが、ソースコードに基づいてソフトウェア開発キットを生成するための自動化処理などの、より大きい処理のサブ処理として実行される。方法200の開始は、これらの例に限定するものではない。
【0023】
最初に、S210において、第1のコードアーチファクトおよび第2のコードアーチファクトが決定される。上述したように、各アーチファクトは、コードの一部分を含み得る。例のために、図3Aは、第1のコードアーチファクト310の一部分を示し、図4Aは、第2のコードアーチファクト410の一部分を示し、これらのコードアーチファクトは、いくつかの実施形態によりS210において決定される。アーチファクト310および410は、JavaScript Object Notation(JSON)形式であるが、諸実施形態は、それに限定するものではない。
【0024】
アーチファクト310は、コードエンティティの階層構造を含むが、諸実施形態は、やはり、それに限定するものではない。本明細書内で明確にするために、エンティティ名は、イタリック体を用いて表す。アーチファクト310のルートレベル(root level)は、エンティティname、description、type、およびheaderを含む。エンティティactivitiesは、エンティティheaderの第1のサブレベルに配置され、エンティティnewInstanceおよびcloseInstanceは、エンティティheaderの第2のサブレベルに(およびエンティティactivitiesの第1のサブレベルに)配置される。エンティティactivitiesの子エンティティは、それぞれエンティティname、async、およびinputsに関連付けられ、そのうちのinputsは、エンティティidentifier、default、optional、およびtypeの親エンティティである。アーチファクト310の各行のエンティティは、値に関連付けられるか(たとえば、“description”: “Collection of functions”)か、または関連付けられない(たとえば、“header”: {)かのいずれかである。本明細書においては、値に関連付けられるエンティティをプロパティと称し、一方、値に関連付けられないエンティティをオブジェクトと称す。
【0025】
アーチファクト410は、いくつかの点でアーチファクト310とは異なる。オブジェクトNewInstanceのプロパティnameの値は、“Open Instance”から“New Instance”に変更されており、オブジェクトNewInstanceのプロパティasyncの値は、“false”から“true”に変更されている。その上、オブジェクトNewInstanceのオブジェクトinputsのプロパティdefaultの値は、“true”から“false”に変更されている。オブジェクトcloseInstanceの名前もまた、closeCurrentInstanceに変更されている。最後に、プロパティoptionalは、オブジェクトcloseInstance(ここでは、名前変更されたcloseCurrentInstance)のオブジェクトinputsから削除されている。
【0026】
次に、S220において、第1のシグネチャが第1のコードアーチファクトに基づいて生成され、第2のシグネチャが第2のコードアーチファクトに基づいて決定される。各シグネチャは、キー/値ペアのリストを含む。本例を続けると、図3Bは、第1のコードアーチファクト310に基づいてS220において生成される第1のシグネチャ320を示している。同様に、図4Bは、第2のコードアーチファクト410に基づいてS220において生成される第2のシグネチャ420を示している。
【0027】
図5の方法500は、いくつかの実施形態によりS220においてコードアーチファクトに基づいてシグネチャを生成するように実行可能である。S220の諸実装形態は、方法500に準拠する方法に限定するものではない。
【0028】
コードアーチファクトの第1のエンティティが、S510において読み出される。アーチファクト310を例として使用すると、読み出されたエンティティは、“name”: “Application”,である。アーチファクト310および410の各行が、単一のエンティティに対応する。したがって、S510は、アーチファクトの単一の行の読出しを含む。エンティティがそのような構造で構成されていないアーチファクトの場合には、S510は、次のエンティティを読み出すために、コードアーチファクトの構文解析を含む。
【0029】
キーが、S520においてエンティティについて作成される。同じアーチファクトについて作成された2つのキーは同一であるべきではないという点で、キーは、アーチファクト内でエンティティを一意に識別すべきである。明確にするために、キーを示すためにこのテキストでは角括弧(「[]」)を使用し、キー/値ペアは、記法<key> → <value>を使用して表す。オブジェクトnameは、アーチファクトのルートレベルにあるので、S520において作成されたキーは、[name]である。
【0030】
次に、S530において、読み出されたエンティティが値に関連付けられるかどうかが決定される。この例によれば、エンティティnameは、値“Application”に関連付けられ、したがって、フローは、S530からS540に進む。S540においては、エンティティについてのキー/値ペアの値は、エンティティに関連付けられる値であると決定される。したがって、記法<key> → <value>を使用すると、エンティティ“name”: “Application”について決定されたキー/値ペアは、name → Applicationである。図3Bは、いくつかの実施形態によりアーチファクト310に基づいて生成されるシグネチャ320を示し、ここで、シグネチャ320の1番目の行は、アーチファクト310の第1のエンティティに基づいて生成されるキー/値ペアを示している。
【0031】
フローがS540からS560に進んで、アーチファクトのいずれかのエンティティがまだ処理されていないかどうかが決定される。そうである場合、フローは、S510に戻る。この例においては、アーチファクト310の第2のエンティティ、および第3のエンティティは、上述したようにS510~S540において処理されて、対応するキー/値ペアdescription → Collection of functions、およびtype → moduleが生成される。これらのキー/値ペアは、シグネチャ320の対応する2番目の行および3番目の行に示されている。
【0032】
フローは、アーチファクト310の第1の、第2の、および第3のエンティティを処理した後、再度、S510に戻る。次のエンティティ(すなわち、“header”: {)を読み出し、対応するキー[header]を生成した後、S530において、エンティティheaderに関連付けられる値が1つもないことが決定される。そのため、フローは、S550に進み、ここで、キー[header]に対応する値は、キーと同一である、すなわち、「header」であると決定される。したがって、アーチファクト310の第4のエンティティについて決定されたキー/値ペアは、シグネチャ320に示されているように、header → headerである。
【0033】
いくつかの実施形態においては、S550は、NULL値、または他の所定の識別子をキー/値ペアの値に割り当てる。概して、諸実施形態は、生成されたキー/値ペアがそのようなものとして識別されることを可能にする任意の方式で、値に関連付けられないエンティティ(すなわち、オブジェクト)についてのキー/値ペアを生成し得る。その結果として、シグネチャにおいて後続の処理を行う任意の下流アルゴリズムが、オブジェクトに関連付けられるキー/値ペアと、プロパティに関連付けられるキー/値ペアとを区別することができるようになる。
【0034】
次いで、フローは、S510に戻って、エンティティ“activities”: {を読み出す。キーが、S520において、読み出されたプロパティについて作成される。いくつかの実施形態によれば、読み出されたエンティティは、親オブジェクト内に配置されるので、作成されたキーは、親オブジェクトのキーに対応する接頭辞を含む。本例においては、親オブジェクトheaderは、キー[header]に関連付けられ、読み出されたエンティティ“activities”: {についてS520において作成されるキーは、[header.activities]である。諸実施形態は、「.」のデリミタに限定するものではない。
【0035】
次いで、S530において、オブジェクトactivitiesに関連付けられる値が1つもないことが決定される。そのため、フローは、S550に進み、ここで、キー[header.activities]に対応する値が、キーと同一である、すなわち、「header.activities」であると決定される。したがって、アーチファクト310の第5のエンティティについて決定されたキー/値ペアは、シグネチャ320において示されているように、header.activities → header.activitiesである。アーチファクト310の第6のエンティティは、上述したようにS510、S520、S530、およびS550において同様に処理されて、対応するキー/値ペアheader.activities.newInstance → header.activities.newInstanceが生成される。このキー/値ペアは、シグネチャ320の6番目の行に示されている。
【0036】
次に、第7のエンティティ“name”: “Open Instance”が、S510において読み出される。上述したように、S520において作成されるキーは、接頭辞として、その親オブジェクトのキー(すなわち、[header.activities.newInstance])を取り、その結果、キー[header.activities.newInstance.name]になる。エンティティのエンティティ型がプロパティであるので、プロパティの値は、S530において、キー/値ペアの値として決定される。結果として生じるキー/値ペアは、header.activities.newInstance.name → Open Instanceとして、シグネチャ320に示されている。
【0037】
方法500は、アーチファクト310の各エンティティについて、まだ処理されていないエンティティが1つもないことがS560において決定されるまで、上述したように進む。この時点では、シグネチャ320は、図3Bに示されているように、生成済みである。とりわけ、シグネチャ320の各キー/値ペアは、シグネチャ320の各他のキー/値ペアとは一意である。そのような一意性は、別のシグネチャとのその後の比較中の、変更されたペアの識別を容易にし得る。
【0038】
図2に戻ると、方法500はまた、S220においてアーチファクト410に適用されて、図4Bのシグネチャ420が生成され得る。諸実施形態は、上述の特定のシグネチャ生成ステップに限定するものではない。しかしながら、生成されたシグネチャのその後の比較は、シグネチャ生成ステップの詳細に関係なく、同じシグネチャ生成ステップを両方のアーチファクトに適用することによって容易にされ得る。
【0039】
これに関しては、第1のシグネチャのキーと第2のシグネチャのキーとの間の複数の変更が、S230において識別される。識別は、第2のシグネチャに存在し第1のシグネチャには存在しないそれらのキー(すなわち、「新規」キー)と、第1のシグネチャに存在し第2のシグネチャに存在しないそれらのキー(すなわち、「削除」キー)と、両方のシグネチャに存在するがその中の異なる値に関連付けられるそれらのキー(すなわち、「更新」キー)とを識別し得る。
【0040】
図6は、いくつかの実施形態によるS230を実装する方法600のフロー図である。第2のシグネチャのキーが、S610において識別される。S620において、第1のシグネチャは、識別されたキーが第1のシグネチャの任意のキーと同一であるかどうかを決定するためにトラバースされる(traversed)。そうである場合、シグネチャ320および420の第1のキーの場合のように、S630において、同一のキーに関連付けられる値も同一であるかどうかが決定される。同一のキーに関連付けられる値も同一である場合、やはりシグネチャ320および420の第1のキーの場合のように、キー/値ペアは、S640において、第1のシグネチャから削除され、フローは、S650からS610に戻って、第2のシグネチャの次のキーを識別する。
【0041】
キーがS620において同一であると決定されるものの、関連付けられた値がS630において同一ではないと決定される場合、シグネチャ320および420の第7のキー/値ペアの場合(すなわち、header.activities.newInstance.name → Open Instanceおよびheader.activities.newInstance.name → New Instance)のように、第2のシグネチャのキー/値ペアは、Updatedリストに追加され、第1のシグネチャのキー/値ペアは、S640において、第1のシグネチャから削除される。
【0042】
S610において識別されるキーが第1のシグネチャに配置されていない(たとえば、すべてのキーが、“closeCurrentInstance”を含む)とS620において決定される場合、第2のシグネチャのキー/値ペアは、S670において、Newリストに追加される。フローは、S650からS610に戻るように進んで、未処理のままである第2のシグネチャのキー/値ペアが存在するかぎり、第2のシグネチャの次のキーを識別する。
【0043】
一旦、第2のシグネチャのキー/値ペアがすべて処理されたと決定すると、フローは、S650からS680に進む。S640におけるキー/値ペアの第1のシグネチャからの削除により、方法600のこの時点において第1のシグネチャにまだ残っている任意のキー/値ペアは、第2のシグネチャにもはや存在しないキーに関連付けられなければならない。したがって、第1のシグネチャに残っている任意のキー/値ペアは、S680において、Removedリストに追加される。
【0044】
図7は、本例のシグネチャ320およびシグネチャ420に基づいて生成されるNewリスト710、Updatedリスト720、およびRemovedリスト730を示している。リスト710~730を使用して、第1のアーチファクトと第2のアーチファクトとの差異を説明する関数コンテキストが解析および提供され得る。とりわけ、リスト710~730は、本明細書に説明する汎用アルゴリズムを使用して任意のオブジェクト指向アーチファクトから生成され得るので、特定のアプリケーションについてコード変更の識別および特性化を望む開発者は、リストの中から対象のキーを識別しリストによって表される変更の関数結果を決定するために使用可能なルールを開発することさえすれば十分である。
【0045】
これに関しては、方法200に戻ると、コードアーチファクトに関連付けられる複数のルールが、S240において識別される。複数のルールは、アーチファクトに関連付けられるアプリケーションに関連付けられ得る。異なるアプリケーションは、異なる解析ルールに関連付けられ得るが、すべての解析ルールが、上述したように生成されるキー/値ペアのリストに働くことができる。解析ルールは、変更に関する関連情報をユーザに提供するのに使用されてもよい。
【0046】
図8は、いくつかの実施形態による解析ルールのスキーマ800を示している。図示のように、各ルールは、ルールの名前、ルールを適用すべきキー/値ペアを識別するのに使用されるキーマッチング属性(key-matching attribute)(たとえば、regex表現)を含む。たとえば、ルールは、activitiesオブジェクトの子オブジェクト(すなわち、activities)に関連付けられ得る。そのため、そのようなルールのキーマッチング属性は、リスト710~730を構文解析して、“header.activities.”が接頭辞として付いたキーを見つけるのに使用可能である場合がある。
【0047】
スキーマ800による各ルールもまた、解析関数に関連付けられる。解析関数は、キーマッチング属性によって識別されるキー/値ペアを処理し、1つまたは複数の対応する解析オブジェクトを生成するように働く。S250において、複数のルールのそれぞれが、複数の変更に基づいて評価されて、複数の解析オブジェクトが生成される。
【0048】
概して、第1の解析ルールは、S250において選択され、そのキーマッチング属性が、マッチングキー/値ペアを変更のリストから識別するのに使用され得る。次いで、解析ルールの解析関数は、キー/値ペアに適用されて、解析オブジェクトが生成される。解析関数は、変更リストの他のキー/値ペアを考慮してもよい。
【0049】
1つの例においては、解析ルールは、第2のアーチファクトによって追加されるアクティビティの数をカウントし得る。したがって、ルールは、アクティビティオブジェクト(たとえば、header.activities.<xxxxxx>)を表すNewリストのすべてのキーを識別しカウントするために実行される。同様に、解析ルールは、Removedリストのキーを構文解析することによって、第2のアーチファクトによって削除されるアクティビティの数をカウントし得る。後者の解析ルールは、各削除されたアクティビティについて警告および/または非互換性メッセージを生成し得る。
【0050】
別の例においては、解析ルールは、第2のアーチファクトによって追加される新規プロパティの数をカウントするように意図される。したがって、解析ルールは、値とキーが同一でない、Newリストのすべてのキー/値ペアを識別し得る。しかしながら、新しいアクティビティが追加された場合には、新しいアクティビティのすべてのプロパティが、Newリストに表されることになる。したがって、解析ルールの解析関数は、(たとえば、上記の例で説明したように)新しく追加されたアクティビティを識別し、それらの新しく追加されたアクティビティのプロパティをカウントしないようにするように働くことができる。
【0051】
別の解析ルールは、入力パラメータが、削除されたかどうか、またはその識別子が変更されたかどうかを、たとえば、そのような変更が望ましくない場合、決定し得る。そのようなルールは、header.activities.<xxxxxxx>.inputsまたはheader.activities.<xxxxxxx>.identifierに準拠するUpdatedリストまたはRemovedリスト内のキーを識別し得る。ルールは、識別されたキーに応じて、対応するメッセージ、警告などを生成し得る。
【0052】
いくつかの実施形態によれば、解析ルールを使用して、プロパティ値に対する特定の変更を識別し、対応するメッセージを生成することができる。たとえば、入力または出力パラメータの型を変更することは、その型が「any」に変更されないかぎり、望ましくない場合がある。したがって、そのようなルールは、型「any」に対する変更ではない出力パラメータ型の値に対する任意の変更を識別し、対応するメッセージ、警告などを生成する。別の例においては、アクティビティのasyncプロパティは、「true」から「false」に変更すべきではない。
【0053】
いくつかの解析ルールは、プロパティ値の、一方の値から他方の値への望ましくない遷移を識別し得る。たとえば、ライフサイクルステータスプロパティの値は、一方の値(たとえば、アクティブ)からより初期の値(たとえば、ベータ)に遷移すべきではない。そのような解析ルールの評価には、更新値に関連付けられるライフサイクルstatusプロパティを識別すること、また第1のアーチファクトにおけるライフサイクルstatusプロパティに関連付けられる値を決定することが必要であり得る。
【0054】
図9は、いくつかの実施形態による解析ルールの解析関数によって作成される解析オブジェクトのスキーマ900を示している。Typeフィールドは、オブジェクト、またはオブジェクトが関係しているプロパティ(たとえば、アクティビティ)を指定することができ、Statusフィールドは、New、Updated、またはRemovedを示すことができ、Messageフィールドは、関数コンテキスト(たとえば、「Activity <xxxxx>は更新されました(Activity <xxxxx> has been updated)」、「#個のアクティビティが削除されました(# activities have been removed)」、「Activity <xxxxx>は非同期から同期に変更されました(Activity <xxxxx> has been changed from asynchronous to synchronous)」)を提供することができる。示されているように、解析オブジェクトはまた、オブジェクトを作成する解析関数によって投入され得るWarningメッセージ(またはレベル)、Importanceインジケータ、および/またはScoreを含んでもよい。S250において生成される解析オブジェクトは、必要に応じて、WarningまたはImportanceによってグループ化されてもよい。
【0055】
解析関数は、変更の型およびステータスに基づいて変更に関連付けられるスコアを決定し得る。スコアは、コードバージョンを更新すべきかどうかの判断に対して、型/ステータスに対する重要度に基づいて解析関数によってハードコード化され得る。非網羅的な例によれば、型ModuleおよびステータスNewの変更は、スコア20に関連付けられ、型ActivityおよびステータスNewの変更は、スコア5に関連付けられ、型ActivityおよびステータスUpdatedの変更は、スコア2に関連付けられ、型Activity.NameおよびステータスNewの変更は、スコア0.01に関連付けられ得る。解析関数によって決定されるスコアは、負であってもよい。たとえば、型ActivityおよびステータスRemovedの変更は、機能を削除する更新が望ましくない場合があるので、スコア-10に関連付けられ得る。
【0056】
可視化は、解析オブジェクトに基づいて、S260において生成され、表される。有利には、解析オブジェクトの汎用スキーマは、アーチファクトが関連付けられるアプリケーションの型に関係なく、同一または類似の可視化ジェネレータの使用を容易にし得る。アプリケーション固有の可視化ジェネレータが、採用されてもよい。
【0057】
図10は、いくつかの実施形態によるS260において生成される可視化1000の図である。可視化1000は、クラウドベースのサーバアプリケーションによって提供されてローカルシステム上で実行するウェブブラウザによって表示されるウェブページを含み得る。可視化1000はまた、スタンドアロンのローカルアプリケーションのユーザインターフェースを含むこともある。諸実施形態は、可視化1000の形式または内容に限定するものではない。
【0058】
可視化1000は、比較の下でコードアーチファクトを識別するエリア1005を含む。可視化1000は、上述したように生成される解析オブジェクトによってカプセル化される情報の可視化を可能にする。この情報は、その任意の適切な視覚的表示をもたらすために、構文解析されても、集約されても、または別の形で使用されてもよい。たとえば、任意の適切なアルゴリズムを採用して、生成された解析オブジェクトに基づいてCompatibilityフラグ1010を決定し、提示してもよい。1つの実装形態においては、Compatibilityフラグ1010は、任意の生成された解析オブジェクトが非互換性変更を示す場合、「いいえ」を示す。
【0059】
Functional scoreエリア1015は、バージョン1.18.28からバージョン1.18.29へのアップグレードに関連付けられる関数スコアを提示する。関数スコアは、上述したように生成される解析オブジェクトに基づいて決定され得る。いくつかの実施形態によれば、関数スコアは、各生成された解析オブジェクトに関連付けられるスコアを合計することによって決定される。関数スコアは、その解釈可能性(interpretability)を向上させるために、0から100の間の範囲に限定される。これに関しては、いくつかの実施形態は、関数スコアの値に基づいているFunctional scoreエリア1015に追加のテキストを提供し得る。たとえば、30未満の関数スコアは、より新しいコードバージョンによって提供される追加の機能がわずかであることに起因して、(図10に示されているように)アップグレードが特に望ましくないことを示すテキストに関連付けられ得る。30から70の間の関数スコアは、アップグレードが有益になり得ることを示すテキストに関連付けられ得るが、70を上回る関数スコアには、アップグレードが多くの新機能を提供することになり、推奨されることを示すテキストがラベル付けされ得る。
【0060】
Overviewエリア1020は、Removed変更、Updated変更、Added変更の簡単な要約を提供する。Overviewエリア1020の内容は、解析オブジェクトのTypeフィールドおよびStatusフィールドに基づいて集約され得る。上述したように、追加されたアクティビティのプロパティは、明確にするために、エリア1020のAdded領域においては無視され得る。
【0061】
By Moduleエリア1030は、対象アプリケーションのモジュールごとにオブジェクト型ごとの変更のカウントを提示する。本例は、変更がコアモジュールにしか存在しないと仮定する。任意の数のモジュールが、いくつかの実施形態に従って解析され得る。
【0062】
What’s Newエリア1040は、生成された解析オブジェクトに関連付けられるメッセージを含み得る。メッセージは、変更の関数コンテキストの理解を容易にすることを意図し得る。同様に、Warningsエリア1050は、解析オブジェクトに関連付けられる任意の警告を含み、Incompatibilitiesエリア1060は、解析オブジェクトに関連付けられる任意の非互換性を含む。これらの警告および非互換性は、上述したように解析ルールの解析関数によって生成される。
【0063】
図11は、いくつかの実施形態によるクラウドベースのシステム1100のブロック図である。これに関しては、アプリケーションサーバ1120およびアーチファクトレポジトリ1130は、セルフサービスおよび即時プロビジョニング、オートスケーリング、セキュリティ、コンプライアンス、およびアイデンティティ管理の機能を提供するパブリッククラウドプロバイダによって割り当てられる、仮想マシンなどのクラウドベースの計算リソースを含み得る。
【0064】
クライアントデバイス1110は、たとえば、クライアントデバイス1110上で実行するウェブブラウザを介して、アプリケーションサーバ1120上で実行するサービスまたはアプリケーションのユーザインターフェースと対話し得る。これらのユーザインターフェースは、サービスまたはアプリケーションの代替バージョンを選択できるようにすることが可能である。代替バージョンを選択すると、本明細書に説明したように、変更識別および特性化方法を開始することができる。方法は、現在のバージョンおよび代替バージョンのアーチファクトを記憶しているアーチファクトレポジトリ1130、ならびに/またはアプリケーションサーバ1120によって実施され得る。方法を実行すると、結果的に、本明細書に説明したように現在のバージョンと代替のバージョンとの間の変更を特性化する可視化の提示につながり得る。
【0065】
前述の諸図は、いくつかの実施形態による方法を説明するための論理アーキテクチャを表し、実際の実装形態は、他の方式で構成されたより多くのまたは異なる構成要素を含んでもよい。他のトポロジーが、他の実施形態と併せて使用されてもよい。その上、本明細書において説明する各構成要素またはデバイスは、任意の数の他のパブリックネットワークおよび/またはプライベートネットワークを介して通信している任意の数のデバイスによって実装されてもよい。そのようなコンピューティングデバイスのうちの2つ以上が、互いにリモートに配置されてもよく、ネットワークおよび/または専用の接続の任意の既知の方式を介して互いに通信していてもよい。各構成要素またはデバイスは、本明細書に説明する機能ならびに任意の他の機能を提供するのに適している任意の数のハードウェア要素および/またはソフトウェア要素を備えることもできる。たとえば、本明細書に説明するアーキテクチャの実装形態に使用される任意のコンピューティングデバイスは、コンピューティングデバイスが本明細書に説明するように動作するような、プログラムコードを実行するプログラマブルプロセッサを含んでいてもよい。
【0066】
本明細書で論じているすべてのシステムおよび方法は、1つまたは複数の非一時的コンピュータ可読媒体上に記憶されているプログラムコードにおいて具現化され得る。そのような媒体としては、たとえば、DVD-ROM、フラッシュドライブ、磁気テープ、およびソリッドステートのランダムアクセスメモリ(RAM)、または読取り専用メモリ(ROM)ストレージ装置を挙げることができる。そのため、諸実施形態は、ハードウェアとソフトウェアとの任意の特定の組合せに限定するものではない。
【0067】
互いに通信していると本明細書に説明する要素は、限定するものではないが、共有メモリ通信、ローカルエリアネットワーク、広域ネットワーク、電話ネットワーク、セルラネットワーク、光ファイバネットワーク、衛星ネットワーク、赤外線ネットワーク、無線周波数ネットワーク、およびデバイス間の情報を伝送するのに使用され得る任意の他のタイプのネットワークを含む、データを転送するための任意の数の異なるシステムを経由して直接または間接的に通信することができる。その上、システム間の通信は、非同期転送モード(ATM)、Internetプロトコル(IP)、ハイパーテキスト転送プロトコル(HTTP)、およびワイヤレスアプリケーションプロトコル(WAP)など、既知である、または既知になる任意の1つまたは複数の伝送プロトコルを経由して行われてもよい。
【0068】
本明細書に説明する諸実施形態は、単に例示の目的のためにすぎない。当業者は、他の実施形態が、上述したものに対する変更形態および代替形態により実施され得ることを認識するであろう。
【符号の説明】
【0069】
100 アーキテクチャ
110 アーチファクトA
115 アーチファクトB
120 シグネチャジェネレータ
130 シグネチャコンパレータ
135 変更
140 変更アナライザ
150 解析ルール
155 解析オブジェクト
160 可視化ジェネレータ
170 可視化
200、500、600 方法
310、410 コードアーチファクト
320、420 シグネチャ
710 Newリスト
720 Updatedリスト
730 Removedリスト
800、900 スキーマ
1000 可視化
1005 コードアーチファクトを識別するエリア
1010 Compatibilityフラグ
1015 Functional scoreエリア
1020 Overviewエリア
1030 By Moduleエリア
1040 What’s Newエリア
1050 Warningsエリア
1060 Incompatibilitiesエリア
1100 システム
1120 アプリケーションサーバ
1130 アーチファクトレポジトリ
図1
図2
図3A
図3B
図4A
図4B
図5
図6
図7
図8
図9
図10
図11
【外国語明細書】