JP2016040714A - ソフトウェアアプリケーションを構成するための方法および装置 - Google Patents

Abstract

【課題】ソフトウェアアプリケーションにおける構成エントリを管理するための解決策を提供する。【解決手段】文脈検索ユニットは、ソフトウェアアプリケーションの文脈であって、１つ又は複数の修飾子を含む文脈を検索する１０。その後、比較ユニットは、１つ又は複数の修飾子をソフトウェアアプリケーションに関する構成識別子を判定するための決定木のノードと比較する１１。判定された構成識別子に基づき、構成値検索ユニットは、ソフトウェアアプリケーションに関する１つ又は複数の構成値を検索する１２。必要な決定木を生成するために、構成識別子判定ユニットは、ソフトウェアアプリケーションに関する構成値に関連付けられた１つ又は複数の構成識別値を判定する。関連付けユニットは、判定された１つ又は複数の構成識別子を決定木のノードと関連付ける。もたらされた決定木は、格納ユニットに格納される。【選択図】図１

Description

本発明は、ソフトウェアアプリケーションを構成するための方法および装置に関する。より詳細には、決定木を使用するソフトウェアアプリケーションを構成するための方法および装置を示す。本発明は、さらに、そのような決定木を生成するための方法および装置に関する。

全てのコンピュータアプリケーションは、上手く動作するための構成を必要とする。その基本レベルにおいて、構成は、キー／バリューペアからなる。アプリケーションがキーを使用する構成システムに要求し、値が返される。

構成セットは、特定の時間においてシステムからの全キー／バリューペアを含む。キーバリューが更新された又は新しいキー／バリューがシステムに追加されたとき、新しい構成セットが作成される。

例えば、視覚効果又は映画ポストプロダクションビジネスにおける演算集約的なタスクを行う企業のソフトウェアスタックは、多くの場合、数百の固有のソフトウェアプロジェクトを含む。それらはおおよそ以下のように分類できる。

１）コアライブラリ、例えば、コンパイル後のバイナリ、Ｐｙｔｈｏｎライブラリなど。

２）プロダクションアプリケーション、例えば、独立型のアプリケーションとして、又はサードパーティ製のアプリケーションを拡張するために、視覚効果アーティストによって使用されるもの。それらはコアライブラリに依存する。

３）企業のインフラストラクチャを維持するために使用されるシステムアプリケーション。それらもコアライブラリに依存する。

安定したシステムを実現するために、全てのソフトウェアコンポーネント（ＡＰＩ（アプリケーションプログラムインタフェース）又はその他）にわたる互換性を確保する必要がある。これは、通常、パッケージ管理システム、例えば、ＰＲＭパッケージマネージャ、Ｄｅｂｉａｎパッケージ管理システム、Ｎｉｘパッケージマネージャ、又はＰｏｒｔａｇｅパッケージ管理システムで実現される。視覚効果ビジネスにおいて、ソフトウェアスタックは更なる要件、すなわち、定性的判定に基づきソフトウェアコンポーネントの組み合わせを定義するための能力を提起する。そのような定性的判定の例としては、

１）特定のプロダクションのためにだけ開発された特徴を組み込む。

２）まだプロダクションの安定版と見なされていない新たに開発された特徴を使用する。

３）全てのソフトウェア変更からソフトウェアスタックを隔離する、すなわち、プロダクションの最終段階においてソフトウェアの安定性を保証する。

４）アプリケーションを異なるサードパーティ製のライブラリ、例えば、物理エンジンと統合する。

５）ライセンス制約が様々なプロダクションの現場間で異なる。

６）ハードウェアの特徴が異なる。

ソフトウェアの互換性と柔軟性を確保して、プロダクションのニーズに従ってワークフローをカスタマイズするために、強力な構成管理システムが必要である。

本発明の目的は、ソフトウェアアプリケーションに関する構成エントリを管理するための解決策を提案することである。

本発明の一態様によると、ソフトウェアアプリケーションを構成するための方法であって、
−ソフトウェアアプリケーションの文脈を検索するステップであって、上記文脈は１つ又は複数の修飾子を含む、ステップと、
−上記１つ又は複数の修飾子を、上記ソフトウェアアプリケーションに関する構成識別子を判定するための決定木のノードと比較するステップと、
−上記判定した構成識別子に基づき、上記ソフトウェアアプリケーションに関する１つ又は複数の構成値を検索するステップと、
を有する。

それに伴い、ソフトウェアアプリケーションを構成するよう構成された装置であって、
−ソフトウェアアプリケーションの文脈を検索するよう構成された文脈検索ユニットであって、上記文脈は１つ又は複数の修飾子を含む、ユニットと、
−上記１つ又は複数の修飾子を、上記ソフトウェアアプリケーションに関する構成識別子を判定するための決定木のノードと比較するよう構成された比較ユニットと、
−上記判定した構成識別子に基づき、上記ソフトウェアアプリケーションに関する１つ又は複数の構成値を検索するよう構成された構成値検索ユニットと、
を備える。

また、ソフトウェアアプリケーションを構成することを可能にする命令を格納したコンピュータ可読記憶媒体であって、コンピュータによって実行されたときに、上記コンピュータに、
−ソフトウェアアプリケーションの文脈を検索するステップであって、上記文脈は１つ又は複数の修飾子を含む、ステップと、
−上記１つ又は複数の修飾子を、上記ソフトウェアアプリケーションに関する構成識別子を判定するための決定木のノードと比較するステップと、
−上記判定した構成識別子に基づき、上記ソフトウェアアプリケーションに関する１つ又は複数の構成値を検索するステップと、
を実行させる上記命令を格納する。

本発明の他の態様によると、ソフトウェアアプリケーションを構成することを可能にする決定木を生成するための方法であって、
−上記ソフトウェアアプリケーションに関する構成値に関連付けられた１つ又は複数の構成識別子を判定するステップと、
−上記判定された１つ又は複数の構成識別子を上記決定木のノードと関連付けるステップと、
−構成管理システムに上記決定木を格納するステップと、
を有する。

それに伴い、ソフトウェアアプリケーションを構成することを可能にする決定木を生成するよう構成された装置であって、
−上記ソフトウェアアプリケーションに関する構成値に関連付けられた１つ又は複数の構成識別子を判定するよう構成された構成識別子判定ユニットと、
−上記判定された１つ又は複数の構成識別子を上記決定木のノードと関連付けるよう構成された関連付けユニットと、
−構成管理システムに上記決定木を格納するよう構成された格納ユニットと、
を備える。

また、ソフトウェアアプリケーションを構成することを可能にする決定木を生成することを可能にする命令を格納したコンピュータ可読記憶媒体であって、コンピュータによって実行されたときに、上記コンピュータに、
−上記ソフトウェアアプリケーションに関する構成値に関連付けられた１つ又は複数の構成識別子を判定するステップと、
−上記判定された１つ又は複数の構成識別子を上記決定木のノードと関連付けるステップと、
−構成管理システムに上記決定木を格納するステップと、
を実行させる上記命令を格納する。

提案する解決策は、好ましくは、低密度な決定木に値を格納する完全に永続的な構成管理システムとして実施される。そのツリーは、入力された修飾子に従って誘導され、好ましくは、バージョニングを通してツリーになされた変更を追跡することを可能にする。上記システムは、ソフトウェアの互換性および柔軟性の両者を保証してプロダクションのニーズに従ってワークフローをカスタマイズする全ての可能性のマトリクスから相等するソフトウェア構成セットを定義する能力を提供する。

本発明の理解を深めるため、ここで図を参照して以下においてより詳細な説明を行う。本発明は、いかなる例示的な実施形態にも限定されず、添付の請求項によって規定される上記本発明の範囲から逸脱することなく、特定の特徴が便宜上組み合わせられ、および／または修正されることも可能である。

ソフトウェアアプリケーションを構成するための発明による方法を模式的に示す図である。 図１の方法を実行するよう構成された装置を模式的に示す図である。 ソフトウェアアプリケーションを構成することを可能にする決定木を生成するための方法による方法を示す図である。 図３の方法を実行するよう構成された装置を示す図である。

ソフトウェアアプリケーションを構成するための発明による方法を図１に模式的に示す。ソフトウェアアプリケーションの文脈であって、１つ又は複数の修飾子を含む文脈を検索した（１０）後、１つ又は複数の修飾子は、ソフトウェアアプリケーションの構成識別子を判定するための決定木のノードと比較される（１１）。判定された構成識別子に基づき、ソフトウェアアプリケーションに関する１つ又は複数の構成値が検索される（１２）。

図２は、図１の方法を実行するよう構成された装置２０を模式的に示す。装置２０は、要求を受信するための入力部２１を備え、ソフトウェアアプリケーションに関する１つ又は複数の構成値を検索する。先ず、文脈検索ユニット２２は、ソフトウェアアプリケーションの文脈であって、１つ又は複数の修飾子を含む文脈を検索する（１０）。その後、比較ユニット２３は、１つ又は複数の修飾子を、ソフトウェアアプリケーションに関する構成識別子を判定するための決定木のノードと比較する（１１）。判定された構成識別子に基づき、構成値検索ユニット２４は、ソフトウェアアプリケーションに関する１つ又は複数の構成値を検索する（１２）。最後に、検索された１つ又は複数の構成値は、出力部２５を介して利用可能にするのに有利である。種々のユニット２２、２３、２４は、専用ハードウェア又はプロセッサ上で実行するソフトウェアのいずれかとして実装される。これらは、単一ユニットに完全に又は部分的に組み込まれることもできる。また、入力部２１および出力部２５は、単一の双方向インタフェースに組み込まれることもできる。

図３は、ソフトウェアアプリケーションを構成することを可能にする決定木を生成するための本発明による方法を示す。先ず、ソフトウェアアプリケーションに関する構成値に関連付けられた１つ又は複数の構成識別子が判定される（３０）。判定された１つ又は複数の構成識別子は、その後、決定木のノードと関連付けられる（３１）。最後に、もたらされた決定木は格納される（３２）。

図３の方法を実行するよう構成された装置４０を図４に模式的に示す。装置４０は、要求を受信するための入力部４１を備えて、決定木を生成する。構成識別子判定ユニット４２は、その後、ソフトウェアアプリケーションに関する構成値に関連付けられた１つ又は複数の構成識別子を判定する（３０）。関連付けユニット４３は、判定された１つ又は複数の構成識別子を決定木のノードと関連付ける（３１）。もたらされた決定木は、装置４０の格納ユニット４４に格納される（３２）。格納ユニット４４は、装置４０の外部にあっても良い。決定木を格納する（３２）代わりに、又はそれに加えて、決定木は、出力部４５を介して利用可能にされる。判定ユニット４２および関連付けユニット４３は、専用ハードウェア又はプロセッサ上で実行するソフトウェアのいずれかとして実装される。これらは、単一ユニットに完全に又は部分的に組み込まれることもできる。また、入力部４１および出力部４５は、単一の双方向インタフェースに組み込まれることもできる。

以下で提案する解決策について、映像ポストプロダクション又は視覚効果の分野における構成管理システムに関してより詳細に説明する。もちろん、この解決策は、この応用に限定されない。

簡易なキー／バリュー構成システムは、値を戻すためにキーの要求のみ行う。例えば、ｖ１からｖ１０の１０バージョンを有するソフトウェアツールTool_Aを考える。システムは、"version for Tool_A"をクエリされ、値"v10"を返す。提案するシステムは、キーと共に修飾子を受け取ることによりこのクエリを拡張する。
software version for Tool_A, production “Foo”-> v10
software version for Tool_A, production “Bar”-> v9

この“production”修飾子は、クエリが行われる環境を記述する。この単純な例において、構成管理システムは、両方のプロダクションに関してTool_Aの異なるバージョンを定義する。この修飾子は、「文脈（context）」として知られ、複合値であり、「要素」からなる。有利には、ユーザに関連する「文脈」が定義され、下記を含むユーザ環境を完全に記述する。
- Job （短縮したプロダクション名）
- Role (アーティスト、開発者、管理者)
- Scene (シーン名、例えば、“build”)
- Shot (ショット名、例えば、“AFA_101”)
- Department (例えば、“animation”、“rigging”、“modelling”)
- Site (例えば、ロンドン、バンクーバ、モントリオール)

全てのコンテキスト構成がクエリのために定義される必要があるとは限らない。上記例に戻ると、構成管理システムに関する有効なクエリは、例えば、下記のようなものである。
software version for Tool_A, Job=WWZ, Scene=“build”,
Shot=”AFA_101”, Site=”London”-> v8
software version for Tool_A, Job=WWZ, Site=”London”-> v9

構成管理システムは、コンテキスト内の値を使用して決定木を使用するクエリを解決する。

構成値は、低密度なツリーに格納され、ツリーの各ノードがコンテキスト要素を表す。例えば、任意の文脈木は下記のように定義され、キー「Ａ」の構成値に低密度に存在する。
root A=10
|--job(a) A=20
| |--scene(a)
| | |--shot(a) A=30
| |--scene(b) A=40
|--job(b)

システムは、キーＡの値に関してクエリされ、文脈を提示する。

決定木が単一ルートノードを含むことも有効である。例えば、
root
| A=1
| C=2
| D=2
| E=2
である。この場合、入力文脈は無視される、すなわち、デフォルトでルートに一致し、単に入力キーが出力値を解決するために使用される。

一実施形態では、決定木に対する変更が記録され、バージョン管理される。実際には固有の暗号ハッシュとして表されるのが好ましいが、簡単にするために増分バージョンナンバーが仮定される。ツリーに対する変更の各セットは、変更が生じた各ノードにおいてバージョン変更として表され、ツリーをルートノードに対してカスケード表示する。ツリーに対するいかなる変更も新たなルートノードバージョンとなる。上記からの例を用いて、文脈ノードを生成するが、下記の例は、構成に対する変更の効果を示す。

初期状態
root [v1]
| A=10
|--node_a [v1] A=20
| |--node_b [v1]
| | |--node_c [v1] A=30
| |--node_d [v1] A=40
|--node_eb [v1]

ケース１：単一ノードに対する更新
この第１の例のnode_a.node_b.node_cは、A=31に変更される。
root [v2]
| A=10
|--node_a [v2] A=20
| |--node_b [v2]
| | |--node_c [v2] A=31 *update*
| |--node_d [v1] A=40
|--node_e [v1]

ケース２：ノードへのデータの追加
ここで値A=50がのnode_eに追加される。
root [v3]
| A=10
|--node_a [v2] A=20
| |--node_b [v2]
| | |--node_c [v2] A=31
| |--node_d [v1] A=40
|--node_e [v2] A=50 *add*

ケース３：１つの新たなグラフでさらに複数の変更
ここでnode_eがA=51に変更され、さらにnode_dがA=41に変更される。
root [v4]
| A=10
|--node_a [v3] A=20
| |--node_b [v2]
| | |--node_c [v2] A=31
| |--node_d [v2] A=41 *update*
|--node_e [v3] A=51 *update*

一実施形態では、構成は、多数の個別のドメインを含む。そのようなドメインの例は、一般的なアプリケーション設定、ソフトウェアバージョン、ソフトウェアパス、又は他の場所との資産の同期である。各ドメインは、それ自体のツリーを有し、通常、多数のドメインが単一のアプリケーションにおいて使用される。例えば、Ｃコンパイルされたアプリケーションは、実行中に、ダイナミックリンクに関する実行ファイルおよび＄ＬＤ＿ＬＩＢＲＡＲＹ＿ＰＡＴＨ環境変数にファイルシステムパスを要求する。上記から、一般的なアプリケーション設定およびソフトウェアバージョンに関連するドメインの組み合わせが要求される。これら２つのドメインの関係は重要であり、システムは、２つの個別のドメイングラフ全体でのグループ化を表する必要がある。この目的に関して、決定木は拡張される。

上記において、簡易な値(例えば、"10")が使用され、特定のキー("A")に従ってノードに返された。ドメインの課題を解決するために、提案するシステムは、個別のドメイン名("Software versions")およびそのルートノードのバージョンによって特定される、ノード上の値が簡易な値("10")又はその他のグラフへの参照を含むことができるように、ドメイン同士のチェーニング（chaining）を可能にする。これは、外部ツリーの明示的なバージョンに対する要求された値の決定を保留することを可能にする。

ノード上の値が参照値、例えば、"Software versions, v99"であり、その後、オリジナルクエリ、すなわち、文脈および要求されたキーが、決定に関して参照されたグラフ上に渡される。

ここで一例を挙げる。ドメイン"X"において下記キー"A"の値を考える。
root [v10]
| A=15
|--job(a) A=25
| |--scene(a)
| | |--shot(a) A=35
| |--scene(b) A=45
|--job(b) A=55
| |--scene(a) A=65

また、ドメイン"Y"において下記キー"A"の値を考える。
root
| A=10
|--job(a) A=20
|--job(a).scene(b) A=30
|--job(b) domainX.v10(A)
|--job(b).scene(c) A=40

ドメインYにおいて値をクエリすることで下記結果が得られる。

一実施形態では、単一の、パブリックの、トップレベルドメインツリーが提供され、全ての構成ドメイン、「構成マネージャ」ドメインにアクセスするためのエントリーポイントとして機能する。これらから、各ドメインが固有の名前又はカテゴリで表される。構成マネージャドメインのデータは連鎖したカテゴリドメインで構成される。

提示されたクエリは３つのコンポーネントで構成され、ここでは、例えば下記３つのカテゴリを含む。

・文脈=job, scene, shot
・カテゴリ='software versions'
・キー='tool_A'.

例示的なトップレベル決定木は下記のように見える。
root [v1]
| ‘software versions’.v11
| ‘software paths’.v12
| ‘application settings’.v2
| ‘sync settings’.v100
|--job(a) ‘application settings’.v3
|--job(b).scene(c) ‘software versions’.v10

ルートノードは、完全な構成システムを表すために全ドメインカテゴリを定義するであろう。

更新が構成ドメインに対してなされるとき、トップレベル決定木のルートノードは、最新のバージョンに更新され、トップレベルツリーの新たなバージョンが生成される。例えば、新たなソフトウェアバージョン構成セットはバージョンｖ１２として利用可能である。
root [v2]
| ‘software versions’.v12
| ‘software paths’.v12
| ‘application settings’.v2
| ‘sync settings’.v100
|--job(a) ‘application settings’.v3
|--job(b).scene(c) ‘software versions’.v10

これは最新の利用可能な構成情報を提供するための柔軟性を与え、一方で文脈が明確にドメインバージョンを定義されているとき、安定性も与える。

Claims (13)

1. ソフトウェアアプリケーションを構成するための方法であって、
   −ソフトウェアアプリケーションの文脈を検索するステップ（１０）であって、前記文脈は１つ又は複数の修飾子を含む、ステップと、
   −前記１つ又は複数の修飾子を、前記ソフトウェアアプリケーションに関する構成識別子を判定するための決定木のノードと比較するステップ（１１）と、
   −前記判定した構成識別子に基づき、前記ソフトウェアアプリケーションに関する１つ又は複数の構成値を検索するステップ（１２）と、
   を有する、前記方法。
2. 前記決定木は、前記決定木のバージョンおよび前記構成識別子のバージョンの少なくとも１つに関する情報を含む、請求項１に記載の方法。
3. 前記決定木は、所与のドメインに固有である、請求項１又は２に記載の方法。
4. 前記決定木は、更なる決定木への参照を含む、請求項３に記載の方法。
5. ソフトウェアアプリケーションを構成するよう構成された装置（２０）であって、
   −ソフトウェアアプリケーションの文脈を検索する（１０）よう構成された文脈検索ユニット（２２）であって、前記文脈が１つ又は複数の修飾子を含む、ユニットと、
   −前記１つ又は複数の修飾子を、前記ソフトウェアアプリケーションに関する構成識別子を判定するための決定木のノードと比較する（１１）よう構成された比較ユニット（２３）と、
   −前記判定した構成識別子に基づき、前記ソフトウェアアプリケーションに関する１つ又は複数の構成値を検索する（１２）よう構成された構成値検索ユニット（２４）と、
   を備えた、前記装置。
6. ソフトウェアアプリケーションを構成することを可能にする命令を格納したコンピュータ可読記憶媒体であって、コンピュータによって実行されたときに、前記コンピュータに、
   −ソフトウェアアプリケーションの文脈を検索するステップ（１０）であって、前記文脈は１つ又は複数の修飾子を含む、ステップと、
   −前記１つ又は複数の修飾子を、前記ソフトウェアアプリケーションに関する構成識別子を判定するための決定木のノードと比較するステップ（１１）と、
   −前記判定した構成識別子に基づき、前記ソフトウェアアプリケーションに関する１つ又は複数の構成値を検索するステップ（１２）と、
   を実行させる前記命令を格納した、前記コンピュータ可読記憶媒体。
7. ソフトウェアアプリケーションを構成することを可能にする決定木を生成するための方法であって、
   −前記ソフトウェアアプリケーションに関する構成値に関連付けられた１つ又は複数の構成識別子を判定するステップ（３０）と、
   −前記判定された１つ又は複数の構成識別子を前記決定木のノードと関連付けるステップ（３１）と、
   −前記決定木を格納するステップ（３２）と、
   を有する、前記方法。
8. 前記決定木に、前記決定木のバージョンおよび前記構成識別子のバージョンの少なくとも１つに関する情報を提供するステップをさらに有する、請求項７に記載の方法。
9. 前記決定木のバージョンに関する情報は、新たな構成識別子が前記決定木に追加されたとき、又は構成識別子が更新されるときに更新される、請求項８に記載の方法。
10. 前記構成識別子のバージョンに関する情報は、前記構成識別子が更新されるときに更新される、請求項８又は９に記載の方法。
11. 前記決定木に更なる決定木への参照を提供するステップをさらに有する、請求項７乃至１０のいずれかに記載の方法。
12. ソフトウェアアプリケーションを構成することを可能にする決定木を生成するよう構成された装置（４０）であって、
    −前記ソフトウェアアプリケーションに関する構成値に関連付けられた１つ又は複数の構成識別子を判定する（３０）よう構成された構成識別子判定ユニット（４２）と、
    −前記判定された１つ又は複数の構成識別子を前記決定木のノードと関連付ける（３１）よう構成された関連付けユニット（４３）と、
    −前記決定木を格納する（３２）よう構成された格納ユニット（４４）と、
    を備えた、前記装置。
13. ソフトウェアアプリケーションを構成することを可能にする決定木を生成することを可能にする命令を格納したコンピュータ可読記憶媒体であって、コンピュータによって実行されたときに、前記コンピュータに、
    −前記ソフトウェアアプリケーションに関する構成値に関連付けられた１つ又は複数の構成識別子を判定するステップ（３０）と、
    −前記判定された１つ又は複数の構成識別子を前記決定木のノードと関連付けるステップ（３１）と、
    −前記決定木を格納するステップ（３２）と、
    を実行させる前記命令を格納した、前記コンピュータ可読記憶媒体。