JP2010534870A - ソフトウェア資産ベースのソリューションを開発する一貫した方法システムおよびコンピュータ・プログラム - Google Patents

Abstract

【課題】ソフトウェア資産ベースのソリューションを開発する一貫した方法システムおよびコンピュータ・プログラムを提供する。
【解決手段】再利用可能なソフトウェア資産を消費する方法、コンピュータ・プログラムおよびシステムであって、前記資産は、要素および属性を用いて記述されており、前記資産は、各自が少なくとも１つのバリアントを含む少なくとも１つの可変要素（ＶＰ）を含んでいる。ユーザは、まず、消費する資産を選択することによって、コンピュータ上のプログラムを実行する。資産に対応しているデシジョン・ツリーがトラバースされる。各デシジョン・ポイントは、可変要素に対応している。デシジョン・ポイントは、対応している可変要素のバリアントを変更するべくユーザの入力を求めることによって処理される。変更された可変要素は保存される。デシジョン・ポイントの依存状態は、可変要素の依存属性によって示される。プログラムは、ユーザの主導で、あるいはデシジョン・ツリーが完全にトラバースされたら、終了することができる。デシジョン・ツリーが部分的にトラバース済みである場合、プログラムは、対応する部分的に変更された可変要素から開始することによって、処理済みの最後のデシジョン・ポイントの後から再始動することができる。
【選択図】図９

Description

本発明は、全般的に、ソフトウェア・ソリューションの開発に関し、特に、本発明は、ソフトウェア資産ベースのソリューションを開発する方法に適用されるものである。

ソフトウェア資産は、後に続くコンテキストにてその資産を繰り返し適用することを目的として作成あるいは獲得された１つ以上の関連した一連の成果物である。資産のコンシューマは、ソリューション・ビジネスのモデリング、分析（使用される資産はモデル）および設計からアプリケーション開発（使用される資産はコードの断片）に至るまで、任意のタイプのＩＴまたはビジネス・プロセス・ソリューションのアーキテクトまたは設計者である。

ＩＴ産業は、ソフトウェア資産のパッケージ化を標準化してきた。オブジェクト管理グループ（ＯＭＧ：Ｏｂｊｅｃｔ Ｍａｎａｇｅｍｅｎｔ Ｇｒｏｕｐ）（ＯＭＧは、米国またはその他の国あるいはその両方におけるＯｂｊｅｃｔ Ｍａｎａｇｅｍｅｎｔ Ｇｒｏｕｐ，Ｉｎｃ．の登録商標または商標である）の再利用可能な資産の仕様（ＲＡＳ：Ｒｅｕｓａｂｌｅ Ａｓｓｅｔ Ｓｐｅｃｉｆｉｃａｔｉｏｎ）は、再利用可能なソフトウェア資産の構造、内容および記述に関する一連のガイドラインおよび勧告である（２００５年１１月の第２．２版を参照のこと）。ＲＡＳは、一貫したパッケージ化を伴った、ソフトウェア資産のカテゴリを特定する。ＲＡＳは、ソフトウェア資産のコンシューマにとってキー・ポイントとなる資産のカスタマイゼーションをサポートしている。ＲＡＳでは、資産とは成果物の入れ物であり、可変ポイントとは、成果物中にあって、コンシューマが対象のソリューションに合わせて変化させるものと予想されるポイントのことである。ＲＡＳの可変性サポートによって、例えば、資産のサブセットのみを消費することなどが可能になる。

２００３年３月６日に公開された米国特許出願公開第２００３／００４６２８２号は、ユーザによる入力に基づいてソフトウェア資産のサブセットを資産ライブラリから選択的に検索する資産検索モジュールを、開示している。この特許出願は目的として、さらに、カスタマイゼーションに向けたコンシューマのデシジョンに基づいたソフトウェア資産へアクセスするステップを容易化するソリューションの提供にも、照準を当てている。ただし、この特許出願の目的としては、資産のアクセスまたは検索よりはむしろ、資産の作成および消費により重点が置かれている。

ソフトウェア資産のパッケージ化およびアクセスに対するサポートを基にして、再利用可能なソフトウェア資産の消費に対する全面的なサポートを提供する必要性がある。ＲＡＳは、ソフトウェア資産をインストール、カスタマイズ、および使用するルールを規定するのに用いることができる。ＲＡＳでは、資産のＵｓａｇｅ（使用法）セクションが、資産をインストール、カスタマイズ、および使用するルールを含んでいる。使用法のテキストは、ユーザによって行われるべき作業、または資産を使用するためのツーリングを記述するとはいえ、この自由形式のテキストは、十分に構造化されたガイダンスは提供しない。

資産を消費するためには、ユーザは、自分が実現を望んでいる資産ベースのソリューションを念頭に置いておく必要もある。ノキア・リサーチ・センタ（Ｎｏｋｉａ Ｒｅｓｅａｒｃｈ Ｃｅｎｔｅｒ）のＡｌｅｘａｎｄｒｅ ＲａｎおよびＪｕｈａ Ｋｕｕｓｅｌａによる、１９９６年のＩＥＥＥ，Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＩＷＳＳＤ−８にて発表された論文「Ｄｅｓｉｇｎ Ｄｅｃｉｓｉｏｎ Ｔｒｅｅｓ」では、これまでのデシジョンによって与えられた設計デシジョン制約の局部的な秩序化である設計デシジョン・ツリーへ、設計パターンの階層的機構を適用することが勧められている。一般にデシジョン・ツリーは、ツリーの１枚の葉（ｌｅａｆ）、すなわち最終目標に達するように、一連のデシジョンでユーザを支援するとよい。ソフトウェア資産のコンシューマは、ソフトウェア資産のセットに対応している設計パターンを適用することによって、デシジョン・ツリーを下ることができるものと考えられる。適切な設計パス、すなわち資産ベースのソリューションが決定されたら、コンシューマは、ＲＡＳなどのリポジトリを使用して、対象のソリューションのソフトウェア資産各々のカスタマイゼーションを実施しなければならない。

この種の手法の主な欠点は、資産プロバイダが、一方で資産リポジトリを作成し、さらに別個の文書を通例はテキスト・ファイル（編集されたテキスト、ＨＴＭＬ、ＸＭＬ、ＳＧＭＬなどを含む）で作成するので、ソフトウェア資産ベースのソリューションを構築している資産のコンシューマは、２つの別個の情報ソース、すなわち消費対象である資産（単数または複数）と、この消費をガイドするデシジョン・ツリーとに依拠することになり、結局２ステップの手法がもたらされてしまう点である：コンシューマは、デシジョン・ツリーをブラウジングしてどのパスを利用するかを決定すること、言い換えれば目標に至るパスを選択することの次に、資産をカスタマイズするべく上記のパスをたどることが必要である。ソフトウェア資産のコンシューマに、２ステップ（パスの決定、ソフトウェア資産のカスタマイゼーション）のプロセスを行わずとも対象のソフトウェア・ソリューションを構築する方法を提供する必要がある。

本発明の目的は、再利用可能なソフトウェア資産のコンシューマに、自分の資産ベースのソリューションを設計すると同時に再利用可能なソフトウェア資産をカスタマイズする方法を、提供することである。

上記の目的は、請求項１に従い、再利用可能なソフトウェア資産を消費するようにコンピュータ上で実行される方法を用いて達成される。各資産は、デシジョン・ツリーに従ってカスタマイズできるようになっており、前記資産は、要素と属性とを含んだ構造的言語を用いて記述されている。一部の要素は可変要素（可変ポイント）であり、各可変要素は、少なくとも１つのバリアント要素（バリアント）を含んでいる。前記方法には、
−ユーザが、１つの選定された資産を消費したい旨コンピュータへ示すステップと、
−コンピュータが、選定された資産の可変要素として各デシジョン・ポイントが体系化されているデシジョン・ツリーを、選定された資産の記述を読むことによって、さらに、デシジョン・ツリーの各デシジョン・ポイントを以下のこと：
−当該可変要素の少なくとも１つのバリアント要素を含んでいるデシジョン・ポイントに関連する可変要素をユーザへ提示すること；
−ユーザから可変要素の変更を収集すること；
−可変要素を適宜変更すること；
−変更された資産の記述を保存すること、
により処理することによって、トラバースするステップと、
が含まれる。

本発明の目的は、さらに、請求項２乃至１２のいずれか１項に従い、再利用可能なソフトウェア資産を消費する方法によって達成される。本発明の目的は、さらに、請求項１３に従い、請求項１乃至１２のいずれか１項による方法のステップを実行するためのプログラミング・コード命令を含むコンピュータ・プログラム製品によって、前記プログラムがコンピュータ上で実行されると、達成される。本発明の目的は、さらに、請求項１４に従い、請求項１乃至１２のいずれか１項による方法を実行するようになっている手段を含むシステムによって、達成される。

本発明の方法を用いると、ソフトウェア資産のコンシューマは、資産を消費するのに行われるデシジョン間の階層的関係を実装している根源的なデシジョン・ツリーによってガイドされる。デシジョン・ツリーは、資産に組み込まれており、各デシジョン・ポイントを資産の中の可変ポイントへとマッピングすることによって体系化されている。デシジョン・ツリーの分岐（１つのデシジョン・ポイントから次のデシジョン・ポイントへのつながり）は、可変ポイントの依存状態によって示される。本方法は、ソフトウェア資産ベースのソリューションを１つのステップで構築することを可能にする。

本ソリューションの利点は、従来のツリーとは相違して、根（ｒｏｏｔ）以外の位置にてデシジョン・ツリーへ入ること、あるいはｌｅａｆではないノードにてデシジョン・ツリーを抜けることが可能な点である。本発明の方法を用いると、デシジョンを記録しながら、ｌｅａｆの段階へ達するより前にストップすることが可能である。これにより、非常に柔軟なツールをサポートする。

本ソリューションのその他の利点を、以下の通り挙げることができる：

−本発明のソリューションを用いると、資産を消費するための規範的なガイダンスと資産自体とが、共に設計上装備され、それにより以下のことが可能になる：
規範的なガイダンスは、矛盾あるいは不一致の生じる余地なく、一貫して資産の構造により決まる：資産とガイダンスとが同調する。
資産プロバイダは、一方のリポジトリへ資産を提供し他方の別のリポジトリへ資産ガイダンス（例えば、テキスト・ファイル）を提供する必要はもはやなくなり、一体化された材料（資産＋ガイダンス）をガイド付き資産データベースへ提供する。
可変ポイントの定義（可変ポイントの依存状態を含む）は、資産の消費についてコンシューマをガイドするのに必要なデシジョン・ツリーのレイアウトを反映する。

−ガイダンスは、全ての分野に関し、一貫してロール（ｒｏｌｅ）によって使用可能となる。このことは協働（適切な引き継ぎを含む）を伴ったエンド−エンドのエンゲージメント・モデルをサポートし、それにより以下のことが可能になる：
これにより、部分的に満たされたパラメータのセットを、その時点で行われていたデシジョンを反映させた状態で、資産と一緒に保存することが可能になる。
資産のコンシューマは、カスタマイズ可能な資産を消費するプロセスにおいて、自分のロールおよび関連スキルに関係のあるデシジョンを済ませたら、ストップすることができる。そのとき資産のコンシューマは、結果として生じる資産を、その後のデシジョンを任されているチーム内の次のコンシューマへと引き継ぐことができる。このプロセスにより、元の資産の可変ポイントを様々なロールが協働して決定することが可能になる。例えば、ビジネス・アナリストが、ビジネス・プロセスに関する全てのデシジョンを行い、次いでこの変更済みの資産を、アーキテクチャ上のデシジョンを行うことのできるソフトウェア・アーキテクトへと引き渡すなどである。
さらに、いずれの段階で行われたデシジョンも自動的に記録され、別途登録する必要はない。

−ガイダンスは、全ての分野に関し、一貫してツールによって使用可能となる：なぜならば、各々の可変ポイントの定義は形式上、標準形式（本実装ではＲＡＳ）で取り込まれているため、現在のデシジョンにより処理されているのが要求、アーキテクチャ、ビジネス・モデリング、設計あるいはコードのいずれであるかに関わらず、ユーザに対するバリアントの提示ならびにデシジョンを行うプロセスは、ツールによって有効にすることができるからである。
資産の内容と規範的なガイダンスとを同じ標準（好適な実施形態ではＲＡＳ）を用いて取り込むことは、ソフトウェア・ベンダにとって、有意な規模の経済につながり得る：単一のツーリング・フレームワークで、ガイダンスおよび資産消費に関して実行者をサポートすることができる。このことは、（各資産タイプ用に専用のツーリングを開発するのとは対照的に）一般的なツーリングからの資産消費を可能にする。

−本発明は、依存状態によってのみ制約されるパラメータの範囲内で複数のパスをもたらす（一般に、依存状態は、ツリーではなくフォレストを生成する）。本発明のツリーは動的であって、消費する方法の各々のコンシューマ工程ごとに、さらにコンシューマの職業上の目的に従って、変更される。

本発明は、再利用可能な資産の仕様ｖ２．２（ＲＡＳ）を用いて実現することができる。本発明は、特定の標準または仕様（ＲＡＳなど）に依存するものではなくＲＡＳを用いて実現してもよいものであるということに、留意しなければならない。故に本発明は、ＲＡＳをサポート（理解）する任意のツールまたはフレームワーク、例えばＩＢＭ Ｒａｔｉｏｎａｌ（ＩＢＭ社の登録商標）ソフトウェア・アーキテクト（ＲＳＡ：Ｒａｔｉｏｎａｌ Ｓｏｆｔｗａｒｅ Ａｒｃｈｉｔｅｃｔ）によって活用可能であるということも、同様に示唆されている。ＲＳＡは、コンポーネント・ベースの（ＳＯＡ、Ｊ２ＥＥおよびポータルの）アプリケーションを作成するソフトウェア・アーキテクトおよびモデル駆動型開発者向けの、モデル駆動型開発および静的解析用ツールである。

本発明の好適な実施形態による、「ガイド付き資産」のデータベースを作成する論理ブロックを示す図である。 本発明の好適な実施形態による、「ガイド付き資産」を消費する論理ブロックを示す図である。 本発明の好適な実施形態による、「ガイド付き資産」を作成する方法のフロー図である。 本発明の好適な実施形態による、「ガイド付き資産」を消費する方法のフロー図である。 本発明の好適な実施形態による、「ガイド付き資産」の一例のＲＡＳ表現を示す図である。 本発明の好適な実施形態による、「ガイド付き資産」の一例のＲＡＳ表現を示す図である。 本発明の好適な実施形態による、「ガイド付き資産」の一例のＲＡＳ表現を示す図である。 図５乃至７で示されたガイド付き資産のＲＡＳ表現により実現されるデシジョン・ツリーのグラフィカルな表現を示す図である。 本発明の別の一実施形態による、複数のエントリ・ポイントを含んでいる「ガイド付き資産」を消費する方法のフロー図である。

好適な実施形態では、本発明を、ＲＡＳ ｖ２．２を用いて実現する。

図１は、本発明の好適な実施形態による、「ガイド付き資産」のデータベースを作成する論理ブロックを示す。ユーザが資産ベースのソリューションを開発できるようにするために、ガイド付きの再利用可能なソフトウェア資産を含んだデータベースを作成する必要がある。一般に資産データベースは、資産リポジトリと称される、データへの容易なアクセスを提供しているリレーショナル・データベースであることが好ましい。以下の本明細書では、データベースもしくはリポジトリは区別なく使用される。リポジトリにおいて、資産は、属性と（モデル、コードである）ファイル成果物自体への関連付けとによって限定される要素を含むＲＡＳなどの構造的言語を用いて、オブジェクトとして記述される。図１は、資産の変更済みの記述を含んだガイド付き資産をリポジトリの中に作成する主要なステップを示す。「ガイド付き資産」の記述には、その資産をどのように消費するかについての情報が含まれており、この情報が、資産のコンシューマに対して段階的なガイダンスを提供することになる。

好適な実施形態では、「ガイド付き資産」データベースを作成する方法は、コンピュータ（１６０）上で実行される資産消費用のソフトウェア・アプリケーション（１２０）における初期動作（１３０、１４０）である。この動作（１３０、１４０）は、資産プロバイダ自身によって実施されてもよいし、あるいはソリューションを開発しガイド付きのソフトウェア資産を自社のＩＴプロフェッショナルへ提供する会社によって実施されてもよい。資産自体（モデル、コード）は、資産リポジトリ（１００）に置かれており、入力として使用される。「ガイド付き資産」作成のフロー図を、後に本明細書にて図３の説明に関連して記載する。全体としては、資産リポジトリから読み取られる各々の資産に関して、資産消費情報（１１０）からデシジョン・ツリーが検索され（１３０）、次いで体系化されて資産に組み込まれる（１４０）。結果として生じる「ガイド付き資産」は、「ガイド付き資産」リポジトリ（１５０）に保存される。

好適な実施形態では、資産消費情報が、「資産消費ガイダンス情報」データベースにテキスト・ファイル（編集されたテキスト、ＨＴＭＬ、ＸＭＬ、ＳＧＭＬなどを含む）として保存されている。こうしたテキスト・ファイルは、プログラムの自動実行によるデータからのデシジョン・ツリーの自動抽出には対処していない。そのため、デシジョン・ツリーの作成（１３０）は、通例、限定されたオペレータ（１３８）によって、ユーザ・インターフェース、好ましくはグラフィカル・ユーザ・インターフェース（１３５）を介して、実施される。ソフトウェア資産消費ガイダンス情報が標準化された方法で保存されていれば、上記の人間の介在はもはや不要である。将来的には、資産プロバイダが資産リポジトリおよび資産情報データベースを維持管理することはもはやなくなり、用意された１つの「ガイド付き資産」リポジトリを直接取り扱うだけになることが分かっている。

さらに、「ガイド付き資産データベース」の作成をもたらす前掲の全てのプログラム（１３０と１３５と１４０）は、別々のコンピュータ上で実施されてもよいことが分かっている。

図２は、本発明の好適な実施形態による、「ガイド付き資産」を消費する論理ブロックを示す。ガイド付き資産リポジトリが構築されたら、ＩＴプロフェッショナル（資産のコンシューマ）は、資産ベースのソリューションを作成するために、同じコンピュータ（１６０）上あるいは別のコンピュータ上で実行可能な資産を消費するプログラム（１２０）の一部（２３０、２４０）を実行することによって、ガイドされてソフトウェア資産をカスタマイズすることになる。資産のコンシューマは、ガイド付き資産データベース（１５０）へ、好ましくはグラフィカル・ユーザ・インターフェース（２００）を介してアクセスし、カスタマイズされたガイド付き資産（２２０）を作成することになる。プログラムは、ユーザに対し、各々の資産に関して、デシジョン・ツリーを表示する（２３０）ことになる。プログラムは、次いで、デシジョン・ツリーの各デシジョン・ポイントにあるユーザの入力を取り込み（２４０）、適宜、ガイド付き資産をカスタマイズすることになる。なお、資産の消費に当たり、当業者には周知なように最終的なソリューション（さらなる使用に向けて更新されたモデルまたはコード）の蓄積が行われることが分かっているが、ソリューションを仕上げるこのステップは、本発明の範囲外にある。

図３は、本発明の好適な実施形態による、「ガイド付き資産」を作成する方法のフロー図である。ガイド付き資産を作成するプログラム（１３０、１４０）は、同じコンピュータ（１６０）あるいは別のコンピュータ上で資産を消費するプログラム（２３０、２４０）が実行されて資産が消費可能になるより前に、コンピュータ（１６０）上にて実行される。

資産リポジトリ・データベース（１００）から第１の資産が読み取られる（３００）。好適な実施形態では、資産は、例えばＲＡＳ ２．２を使用するなど標準化されたやり方でデータベースに保存されている。資産が検出された場合（検証３１０に対する回答が、はい）、資産消費ガイダンス情報データベース（１１０）から、対応するデシジョン・ツリーが抽出される（３２０）。

ｒｏｏｔとなるデシジョン・ポイントが特定される（３３０）。これは、デシジョン・ツリーの分岐へと向かう、最初の可能な選択肢に相当する。次のステップは、先に特定されたデシジョン・ポイント（３３０）で入手可能な情報、および資産消費ガイダンス情報データベース（１１０）から先に抽出されたツリー（３２０）に含まれている情報を用いることによって、資産の中に可変ポイント（ＶＰ：ｖａｒｉａｂｉｌｉｔｙ ｐｏｉｎｔ）を作成しさらにこのＶＰの属性を設定する（３４０）ことである。上記の情報としては、以下が挙げられる：
デシジョン・ポイントの名称：この名称は、可変ポイント（デシジョン・ポイント）を一意に特定するために、その資産内では一意となっている必要がある；
記述：これは人（ユーザ）に向けたテキスト情報であり、このポイントで行われるべきデシジョンを記述している。
バリアントのセット：デシジョン・ポイントには、もとから資産とパッケージになっている少なくとも１つの可能な選択肢または取り得る手段（以下の本明細書では「バリアント」と称されるもの）のセットが含まれる。さらに、資産のコンシューマによって何も変更がなされない場合、こうしたバリアントのうちの１つが、デフォルトで使用されるバリアントとなることもある。
バリアントのタイプ：デシジョン・ポイントでは、或る特定のタイプのバリアントのみが受け入れ可能となっている。こうしたバリアントは、置き換えることもできる（例えば、モデル、コードなど）；
バリアント間の共生のルールを特定するパラメータ（例えばバリアント論理：包含的、排他的、任意的など）；
ツール：自動化およびコンテキストをサポートするために、各々の可変（デシジョン）ポイントは、その処理が可能なソフトウェア・ツール（デシジョンを行うのに使用可能なツール）を列挙する必要がある。図５乃至７が、可変ポイントの詳細な事例を示している；
デシジョン・ツリーにおけるデシジョン・ポイントの場所を特定するパラメータ：例えばこれは、ツリーにおいて先行するノードの名称である可能性が考えられる。

ツリーの全てのデシジョン・ポイントが探索済みとなるまで、すなわちデシジョン・ツリーにてそれ以上子がなくなる（検証３５０に対する回答が、Ｎとなる）まで、同じステップ（３４０）が繰り返される（検証３５０に対する回答が、はい）。その後、ガイド付き資産はガイド付き資産リポジトリ（１５０）へ保存され、次の資産が、資産リポジトリから読み取られる（３００）。

抽出されるデシジョン・ツリー（３２０）、およびＶＰの属性を満たす情報（３４０）は、こうしたデータが資産消費ガイダンス情報データベース（１１０）に標準的なやり方で保存されている場合に限り、資産を消費するプログラム（１２０）による自動的な実行が可能であると分かっている。図１の説明に関連して先に述べたように、上記の情報は、現在一般には標準化されておらず、オペレータ（１３８）が、ユーザ・インターフェース好ましくはグラフィカル・ユーザ・インターフェース（１３５）を備えたプログラムによって、情報がプログラム（１２０）によって消費可能となるようなやり方で、資産消費ガイダンス情報データベース（１１０）の中に情報を作成する最初のステップを実施するとよい。このステップは、ガイド付き資産の作成期に同時に実施することもできる。

図４は、本発明の好適な実施形態による、「ガイド付き資産」を消費するフロー図である。資産を消費するプログラム（１２０）のこの部分は、ガイド付き資産の作成に使用されたコンピュータと同じであっても別であってもよいコンピュータ（１６０）上で実行される。資産のコンシューマ（ＩＴプロフェッショナル）は、好ましくはグラフィカル・ユーザ・インターフェース（一般的には、ウィザード）を介して、プログラムの上記の部分と対話する。ユーザは、自分が開発している資産ベースのソリューションに、どの資産を含める必要があるかを認識している。ユーザは、自分の開発しているソリューションの細目に従って資産をカスタマイズするようにガイドされることになる。

最初のステップは、ユーザが資産を選定できるスクリーンをグラフィカル・ユーザ・インターフェースによって表示する（４００）ことである。資産が選定されたら（検証４１０に対する回答が、はい）、プログラムによって、対応するデシジョン・ツリーのｒｏｏｔの可変ポイントの位置を特定する（４２０）。ｒｏｏｔに対応するＶＰ記述が表示され（４３０）、ユーザが、ｒｏｏｔ ＶＰへ変更をもたらすように入力を行い、ＶＰの内容を変更することによって自分のカスタマイゼーションの選択を反映させる。コンピュータが、ユーザによって提示された通りにＶＰ記述を更新する（４４０）。この資産の以降のデシジョン・ポイント（検証４５０に対する回答が、はい）は、デシジョン・ツリーがトラバースされるまで、すなわち全てのノードが訪れられる（検証４５０に対する回答が、いいえ）まで、ユーザによって選定されれば（検証４６０に対する回答が、はい）、表示され更新される（４３０、４４０）。デシジョン・ツリーは、或る同じデシジョン・ポイントに依存している全てのデシジョン・ポイントを訪ねることによってトラバースすることもできるし、あるいは連続的に各分岐を訪ねることによってトラバースすることもできることが分かっており、あらゆるオプションが可能であって、言い換えれば、デシジョン・ポイント間の依存関係に従っているのであれば、あらゆるツリー・トラバースの戦略およびアルゴリズムが使用可能である。上記は、本方法を１工程で実行することによって資産をカスタマイズする、第１のオプションである。本明細書で後に図７を参照してさらに詳述するもう１つの可能性は、資産を複数の工程でカスタマイズすることである。この場合、第１の工程は、ユーザがストップすると決めたとき（検証４６０に対する回答が、いいえ）に、終了することができる。このことは、そのカスタマイゼーションの結果が、部分的に消費された資産となることを意味する。図４は、ガイド付き資産を消費する第１の工程を表したものである。

資産のコンシューマは、以下のことが要因となって、資産の消費に向けた自分の選択を入力するようにガイドされる（４３０）：
−デシジョン・ポイントが、ツリーの依存状態に従って連続的に表示される；
−各々のデシジョン・ポイントにて、コンピュータが、ＶＰおよび全てのＶＰバリアントの記述を表示する。

ステップ４４０にて、コンシューマの選択を入力することによりガイド付き資産が更新される。コンシューマの選択は、デシジョン・ポイントをマッピングしているＶＰへ適用される。こうして、コンシューマによる選択を記録する。コンシューマは、ＶＰの記述にあるものは何でも変えることができる：バリアント間の共生のルールに従ってバリアントを削除または追加すること、バリアントの属性を変更することなどである。以下、資産を記述する構造的言語を、本明細書の図５乃至７に関連して説明する。

図５乃至７は、本発明の好適な実施形態による、「ガイド付き資産」のＲＡＳ表現であり、完全に記述されたデシジョン・ポイントを示している。これらの詳細は、本発明がどのように機能するか説明することを唯一の目的として提示するものであり、本発明を、ここではＲＡＳ ｖ２．２である、いずれかの構造的言語をベースに使ってどのように実現するべきかという限定的な定義ではないことに留意願いたい。さらに、好適な実施形態では、ＲＡＳ２．２の拡張を提案するのではなく、同じ要素および属性を使用しているが、そのうちの一部は固有のセマンティックスで使用している。本例では、一連のアプリケーション・コンポーネントのソース・コードの実装からなるソフトウェア資産が、電気通信産業において例えばｅＴＯＭ（電気通信産業における、ビジネス・プロセスを標準化しているＥｎｈａｎｃｅｄ Ｔｅｌｅｃｏｍ Ｏｐｅｒａｔｉｏｎ Ｍａｐｓ：拡張電気通信事業者オペレーション・マップ）などで定義されているサービス構成と起動（Ｓｅｒｖｉｃｅ Ｃｏｎｆｉｇｕｒａｔｉｏｎ ａｎｄ Ａｃｔｉｖａｔｉｏｎ）をサポートするものとみなしている。

より正確には、この資産は、（サービス・オーダー管理システム（Ｓｅｒｖｉｃｅ Ｏｒｄｅｒ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）内部の）サービス構築実装（Ｓｅｒｖｉｃｅ Ｃｏｎｓｔｒｕｃｔｉｏｎ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）がいくつかの可能な選択肢を備えて提案され、さらに（サービス起動管理システム（Ｓｅｒｖｉｃｅ Ａｃｔｉｖａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）内部の）重要業績評価指標コンプライアンス・チェック（Ｋｅｙ Ｐｅｒｆｏｒｍａｎｃｅ Ｉｎｄｉｃａｔｏｒ Ｃｏｍｐｌｉａｎｃｅ Ｃｈｅｃｋ）もほかの選択可能な実装を装備するやり方で、設計されている。電気通信業界では、ビジネス・プロセスは極めて安定しているが、ビジネス・プロセスのステップの実装は、企業内の機能あるいは外部の機能のいずれを使用するかに応じて異なってくる。本例では、資産プロバイダによってそのように設計されていれば、資産のコンシューマは、サービス構築の特定の選択肢を選ぶと、次に（サービス設計システム（Ｓｅｒｖｉｃｅ Ｄｅｓｉｇｎ Ｓｙｓｔｅｍ）内部の）いくつかの外部オーダー作成（Ｅｘｔｅｒｎａｌ Ｏｒｄｅｒ Ｃｒｅａｔｉｏｎ）実装の中から選択することが可能になる。

図５乃至７は、上述のような資産の例として、ガイド付き資産の、ＲＡＳに基づいた簡略化された定義を示す。この定義は、分かりやすくするために簡略化されている。この定義はＲＡＳ２．２に適合しているが、ＲＡＳ２．２を採り入れたくなければ、資産を記述する他の任意の構文オプションを適応させることも可能と考えられる。このガイド付き資産の定義は、図１および３に記載した方法を実行することによって作成される。ＲＡＳは、要素（＜ａｓｓｅｔ＞、＜ｃｌａｓｓｉｆｉｃａｔｉｏｎ＞、＜ＶａｒｉａｂｉｌｉｔｙＰｏｉｎｔ＞、＜ａｒｔｉｆａｃｔ＞など）を用いてオブジェクトを記述する、構造的言語である。各要素は、属性（ｉｄ、ｄｅｓｃｒｉｐｔｉｏｎ（記述）、ｒｅｆｅｒｅｎｃｅ（参照）など）を有している。

この記述は、最初に図５の＜ａｓｓｅｔ＞タグを有し、最後に図７の＜／ａｓｓｅｔ＞タグを有するＸＭＬテキストである。中間では、多様なａｒｔｉｆａｃｔ（成果物）のタグが、本明細書にて図１および３の説明に関連して先に記載したように、資産の様々な可変ポイントならびにそのバリアントを記述している。これらの可変ポイントは、図８で示すように、対応している資産のデシジョン・ツリーのデシジョン・ポイントへとマッピングされる。デシジョン・ツリーのデシジョン・ポイントは、本方法を図２および図４に記載するように実行するに当たり資産のコンシューマが選択しなければならない、資産カスタマイゼーションにおける様々なオプションに相当する。

図６では、２つのａｒｔｉｆａｃｔにおいて２つの可変ポイントが記述されている。ａｒｔｉｆａｃｔ“電気通信業界サービス構成と起動コンポーネント”では、“資産の消費”の“ｒｏｏｔ”可変ポイント（ＶＰ）が記述され、ａｒｔｉｆａｃｔ“サービス構築”では、“サービス構築実装”の“ｖｐ１”可変ポイントが記述されている。

図６では、ｒｏｏｔ ＶＰは、図３で示したような資産のカスタマイゼーションのための通常のエントリとなっており、カスタマイゼーションのための可能な選択肢は存在せず、すなわち「バリアント」がない。属性「ｒｅｆｅｒｅｎｃｅ」は、ｒｏｏｔデシジョン・ポイントの、デシジョン・ツリーにおける場所を記述する（ｒｏｏｔには先行するものがないため、空になっている）。より一般的には、この「ｒｅｆｅｒｅｎｃｅ」属性は、当該ＶＰの、デシジョン・ツリーにおける依存状態を限定する。ＶＰの記述、バリアントのタイプ、ならびにバリアント間の共生を導くルールがもしあれば、属性「ｃｏｎｔｅｘｔ−ｉｄ」によって提示される。ｒｏｏｔ ＶＰに関する「ｃｏｎｔｅｘｔ−ｉｄ」の値は、“ｃｔｘｔ１”である。ＲＡＳ２．２に適合していることから、図５において、全てのＶＰの「ｃｏｎｔｅｘｔ−ｉｄ」の値が、包括的な＜ｃｌａｓｓｉｆｉｃａｔｉｏｎ＞タグの内の＜ｃｏｎｔｅｘｔ＞タグの下に列挙されている。“ｃｔｘｔ１”に関しては、バリアントが何もないため、図５における記述は、名称および記述のみを含んでいる。

図６は、ｖｐ１デシジョン・ポイントでは、資産のコンシューマがカスタマイゼーションのための選択を行うことを示している。ｖｐ１ ＶＰは、ａｒｔｉｆａｃｔ“サービス構築実装オプション１”、“サービス構築実装オプション２”および“サービス構築実装オプション３”でそれぞれ記述される３つのバリアントを有する。ｖｐ１は、本デシジョン・ツリーにおいてｒｏｏｔに依存しているので、ｖｐ１ ＶＰの属性「ｒｅｆｅｒｅｎｃｅ」は、ｒｏｏｔ（ｒｅｆｅｒｅｎｃｅ＝“ｒｏｏｔ”）である。ｖｐ１ ＶＰの「ｃｏｎｔｅｘｔ−ｉｄ」の値は“ｃｔｘｔ２”である。“ｃｔｘｔ２”に関しては、図５における記述は、名称、記述、バリアント・タイプ、および共生ルール（“ｅｘｃｌｕｓｉｖｅ（排他的）”）を含んでいる。

図７では、２つのａｒｔｉｆａｃｔに関して２つの可変ポイントが記述されている。ａｒｔｉｆａｃｔ“サービス設計システム”では、“外部オーダー作成実装”の“ｖｐ２”可変ポイント（ＶＰ）が記述され、ａｒｔｉｆａｃｔ“ＫＰＩコンプライアンス・チェック”では、“ＫＰＩコンプライアンス・チェック実装”の“ｖｐ３”可変ポイントが記述されている。

図７では、“ｖｐ２”ＶＰは、ａｒｔｉｆａｃｔ“外部オーダー作成実装オプション１”および“外部オーダー作成実装オプション２”でそれぞれ記述される２つのバリアントを有する。ｖｐ２ ＶＰの属性「ｒｅｆｅｒｅｎｃｅ」は、ｖｐ１である（ｒｅｆｅｒｅｎｃｅ＝“ｖｐ１”、デシジョン・ツリーにおける親ノード）。ｖｐ２ ＶＰの「ｃｏｎｔｅｘｔ−ｉｄ」の値は“ｃｔｘｔ３”である。“ｃｔｘｔ３”に関しては、図５における記述は、名称、記述、バリアント・タイプ、および共生ルール（“ｅｘｃｌｕｓｉｖｅ”）を含んでいる。

図７では、ｖｐ３ ＶＰは、ａｒｔｉｆａｃｔ“ＫＰＩコンプライアンス・チェック・オプション１”およびａｒｔｉｆａｃｔ“ＫＰＩコンプライアンス・チェック・オプション２”でそれぞれ記述される２つのバリアントを有する。ｖｐ３ ＶＰの属性「ｒｅｆｅｒｅｎｃｅ」はｒｏｏｔである（ｒｅｆｅｒｅｎｃｅ＝“ｒｏｏｔ”、デシジョン・ツリーにおける親ノード）。ｖｐ３ ＶＰの「ｃｏｎｔｅｘｔ−ｉｄ」の値は”ｃｔｘｔ４”である。”ｃｔｘｔ４”に関しては、図５における記述は、名称、記述、バリアント・タイプ、および共生ルール（“ｅｘｃｌｕｓｉｖｅ”）を含んでいる。

上述のように、可変ポイントとそのバリアントとは、同一のコンテキストを示すことによって関連付けられており、コンテキスト定義には、バリアントを組み合わせるあるいは組み合わせないルール（本例では排他的となっている）、ならびに受け入れ可能なバリアントのタイプ（Ｊ２ＥＥ エンタープライズ・アーカイブ、Ｊａｖａ（Ｒ）アーカイブ・ファイル、Ｊａｖａ（Ｒ）ファイル）というような、詳細が含まれる。

可変ポイント“サービス構築実装”および“ＫＰＩコンプライアンス・チェック実装”は、本デシジョン・ツリーのｒｏｏｔを表している“資産の消費”可変ポイントを参照する。このことは、本デシジョン・ツリーへのエントリ・ポイントを反映している。

可変ポイント“外部オーダー作成実装”は、可変ポイント“サービス構築実装”を参照する。このことは、本デシジョン・ツリー構造における依存状態を反映している。

この好適な実施形態は、例外はあるものの、ＲＡＳ ｖ２．２をそのまま使用している。ＲＡＳでは、ＶａｒｉａｂｉｌｉｔｙＰｏｉｎｔにおけるｒｅｆｅｒｅｎｃｅ属性を使って、さらなるバックグラウンドならびに説明を備えることもできる；ここでは、＜ｖａｒｉａｂｉｌｉｔｙ−ｐｏｉｎｔ＞ＸＭＬタグにて“ｒｅｆｅｒｅｎｃｅ”属性のセマンティックスを変え、本デシジョン・ツリーの構造を反映している可変ポイント間の先行関係、言い換えれば各デシジョン・ポイントを検討するべき順序を、取り込むようにした。

図８は、図５乃至７のＲＡＳ表現で示されたガイド付き資産のデシジョン・ツリーが意味する依存状態ツリー（６００）のグラフィカルな表現である。デシジョン・ポイントは、ｒｏｏｔ、ｖｐ１、ｖｐ２、ｖｐ３である。以下の依存状態が示されている：ｖｐ２は、ｖｐ１に依存する；ｖｐ１およびｖｐ３は、ｒｏｏｔに依存する。好適な実施形態では、依存状態は、ガイド付き資産における、当該ＶＰの「ｒｅｆｅｒｅｎｃｅ」属性の値に対応する。各デシジョン・ポイントに関し、依存状態によってデシジョン・ツリーの可能な分岐が体系化されている。

１つの資産に関連する消費ガイダンス情報（１１０）が、設計モデルおよび実装モデルを含んでいる場合、その資産には２つの自然発生的な論理デシジョン・ツリーが存在する：設計ツリーおよび実装ツリーである。ガイド付き資産の内部に構築されるデシジョン・ツリーは１つだけであり、言い換えれば、資産につき１つのデシジョン・ツリーがある。或る資産に複数の自然発生的な論理ツリーが存在する場合、冒頭に、ｒｏｏｔと称される１つのデシジョン・ポイント（可変ポイント）を追加する。次にｒｏｏｔ可変ポイントが、ユーザに対し、どちらの自然発生的な論理ツリーを通過したいか（本例では、ユーザが設計モデルまたは実装モデルのいずれを消費したいか）を単純に尋ねる。このことは、ガイド付き資産の消費をガイドするのに、常に唯一のデシジョン・ツリーが存在することを確実にする。その後、資産を消費する方法により、依存状態によってのみ制約されるパラメータの範囲内で複数のパスがもたらされる。

図８では、ツリー６１０、６２０および６３０が、図５乃至７のガイド付き資産を消費する３つのやり方を説明している。６１０では、コンシューマは、サービス構築実装ｖｐ１デシジョン・ポイントのオプション１を選択し、これは、（“ｃｔｘｔ２”コンテキストの記述によれば）残りのバリアント（オプション２およびオプション３）に対して排他的である。次に、コンシューマは、外部オーダー作成実装ｖｐ２デシジョン・ポイントにて、オプション２を選択する。

６２０の消費対象の資産については、ユーザが、この資産を消費しないと決めたため、ガイド付き資産に何も変化が生じていない。６３０では、資産のコンシューマは、デシジョン・ツリーの一連のデシジョン・ポイントにて、別のバリアントを選択している。

ガイド付き資産を消費する本方法を、複数の工程を可能にするように拡張したものを、図９のフロー図に記載する。資産を消費する第１の工程は既に実施済み（図４）であるが、ガイド付き資産のデシジョン・ツリーは、完全にはトラバースされていない、すなわちツリーのデシジョン・ポイントの全てが処理（４３０、４４０）されてはいないと仮定する：デシジョン・ツリーの処理されていないデシジョン・ポイントに対応する可変ポイントは、更新（４４０）されていない。第１工程に後続する工程の場合、コンシューマは、１つの「エントリ・ポイント」によって、デシジョン・ツリー探索へ再度入ることができる。このエントリ・ポイントは、前の工程にて既に処理（４３０、４４０）されたデシジョン・ポイントであってもよいし、あるいは、既に訪れた最後のデシジョン・ポイントの（依存状態ツリーにおいて）次に続くデシジョン・ポイントであってもよい。この、より一般的な図９のフロー図では、コンシューマは、図４の第１工程のフロー図では唯一のエントリ・ポイントであったデシジョン・ツリーのｒｏｏｔを含んだデシジョン・ツリーの全エントリ・ポイントの中から、１つのエントリ・ポイントを選択するように提案される。

ユーザが選定した（検証４１０に対する回答が、はい）ガイド付き資産をコンピュータが読み取る（４００）と、コンピュータは、資産の、エントリ可変ポイントの位置を特定する（７００）：前の工程で全てのデシジョン・ポイントが処理されていない場合（検証７１０に対する回答が、はい）、コンシューマは、そのうちの１つを選定するように求められ、１つが選定されると（検証７２０に対する回答が、はい）、そのデシジョン・ポイントが処理される。すなわち、ユーザは自分の選択を入力するように求められ（４３０）、コンピュータが対応する資産の可変ポイントを適宜更新する（４４０）。今しがた処理されたデシジョン・ポイントの可変ポイントを削除し、さらにこの資産の依存状態ツリーの後続するデシジョン・ポイント（単数または複数）すなわち本デシジョン・ツリーの子を追加することによってエントリ・ポイントのリストを維持管理する、新しいステップ（７３０）が追加される。上記のリストは、コンピュータによって読み取られて、全てのエントリ・ポイントの位置特定に向けた次のステップ（７００）が実行される。

ガイド付き資産を消費するプログラムは、コンシューマが資産の消費を選択しない（検証４１０に対する回答が、いいえ）ことを理由に終了してもよい。もはや残っているエントリ・ポイントがない（検証７１０に対する回答が、いいえ）ためにコンピュータによってエントリ・ポイントが検出されない場合、あるいは残っているエントリ・ポイントの処理がコンシューマによって選択されない場合（検証７２０に対する回答が、いいえ）には、選定された資産の処理は終えられ、コンピュータが、資産を、資産が処理されたままの状態で、すなわちコンシューマによって完全に消費された（検証７１０に対する回答が、いいえ）資産としてあるいはコンシューマによって部分的に消費された（検証７２０に対する回答が、いいえ）資産として、保存する（７４０）。

図９のフロー図で示されたプロセスの変形例は、コンシューマが、ガイド付き資産の一部分のみを消費した場合（検証７２０に対する回答が、いいえ）に、この部分的に消費されたガイド付き資産を、新しいガイド付き資産として保存する（検証７２０に対する回答が、いいえ）ものである。そうする理由は、資産の消費のされ方によって決まる。コンシューマは、デシジョン・ポイントを、対応するＶＰのバリアントを選択することによって、処理（４３０、４４０）すればよい。その一方で、デシジョン・ポイントでは、コンシューマは、例えば図６のガイド付き資産の記述に示されるように＜ｒｅｆｅｒｅｎｃｅ ｖａｌｕｅ＝ファイル名．ｊａｒ＞を追加することによって、新しいバリアントの追加および対応するコードの追加を行い、対応するＶＰを強化（４３０、４４０）してもよい。結果として生じる変更されたガイド付き資産は、その後のコンシューマにとって有用となる可能性があり、この場合、強化されたガイド付き資産という結果を新しい「ガイド付き資産」として保存することは、有利となり得る。次の、強化されたガイド付き資産のコンシューマは、まだ処理されていないデシジョン・ポイントを処理することによって、このガイド付き資産をカスタマイズすることになる。プロフェッショナルの能力およびコンシューマの選好に従い、さらには使用されている構造的言語（ＲＡＳ）に応じて、ＶＰを変更する（４３０）その他のやり方もあり得る。

デシジョン・ポイントの処理および対応する可変ポイントの変更は、資産の作成時に発生する（デフォルト値）可能性もあり、あるいは別のコンシューマによる資産の消費時に発生する可能性もある。例えば、設計者が資産を入手し設計上のデシジョンを行わねばならないときに、その資産に関するアーキテクチャ上のデシジョンはアーキテクトによって既に行われている場合もある。

一般に、部分的に消費された資産は、同じユーザによるその後の消費、あるいは、資産の消費に関して様々なロール（アーキテクト、設計者、セキュリティに関するスペシャリストのＩＴプロフェッショナルなど）で機能している他のユーザによるその後の消費に向けて、保存される（７４０）。

図９は、資産のコンシューマが、カスタマイズ可能な資産を消費するプロセスにおいて、自分のロールおよび関連スキルに関係のあるデシジョンを行ったらストップすることができるという、本発明のソリューションの有力な利点を示している。そのとき資産のコンシューマは、結果として生じる資産を、その後のデシジョンを行うことを任されているチーム内の次のコンシューマへと引き継ぐことができる。本明細書にて先に述べたように、この方法により、元の資産の可変ポイントを、様々なプロフェッショナルが協働して決定することが可能になる。様々なプロフェッショナルとは、例えば、ビジネス・アナリスト、設計者としてのソフトウェア・アーキテクト、ならびにセキュリティ実装に関する別の設計スペシャリストなどである。

なお、所与の資産において体系化されたツリーは１つのみとなっているが、ユーザに対して複数のエントリ・ポイントを提供することは、資産の消費をガイドする複数のツリー（サブツリー群）を提供することに極めて類似するということが分かっている。

Claims (14)

1. 再利用可能なソフトウェア資産を消費するようにコンピュータ上で実行される方法であって、各資産は、デシジョン・ツリーに従ってカスタマイズできるようになっており、前記資産は、要素と属性とを含んだ構造的言語（ＲＡＳ）を用いて記述されており、一部の要素は、可変要素（可変ポイント）であり、各可変要素は、少なくとも１つのバリアント要素を含み、前記方法は、
   −前記ユーザが、１つの選定された資産を消費したい旨を前記コンピュータへ示す（４００）ステップと、
   −前記コンピュータが、前記選定された資産の可変要素として各デシジョン・ポイントが体系化されているデシジョン・ツリーを、前記選択された資産の前記記述を読むことによって、さらに、前記デシジョン・ツリーの各デシジョン・ポイントを以下のこと：
   −前記可変要素の前記少なくとも１つのバリアントを含む前記デシジョン・ポイントに関連する前記可変要素をユーザに提示する（４３０）こと；
   −前記可変要素の変更を前記ユーザから収集する（４３０）こと；
   −前記可変要素を適宜変更する（４４０）こと；および
   −前記変更された資産の記述を保存する（７４０）こと、
   により処理することによって、トラバースするステップと、
   を含む、方法。
2. 前記デシジョン・ツリーをトラバースする前記ステップは、１つの工程で実施される、請求項１に記載の方法。
3. 前記デシジョン・ツリーをトラバースする前記ステップは、前記デシジョン・ツリー全体をトラバースするのに必要なだけの数の工程で、部分的にトラバースする各工程において、前の前記部分的にトラバースする工程にて保存された前記変更された資産の記述を読むことと、前記前の工程の期間中に前記最後に処理されたデシジョン・ポイント（単数または複数）の後から各デシジョン・ポイントの前記処理を開始することと、によって繰り返し部分的に実施される、請求項１に記載の方法。
4. 前記デシジョン・ツリーをトラバースする前記ステップが、
   −ｒｏｏｔの識別属性を有する前記可変要素（４２０）を読むステップと、
   −ｒｏｏｔの依存属性を有する前記可変要素全てを読むステップと、
   −ｒｏｏｔに依存している前記可変要素の前記識別属性を読むステップと、
   −既に読まれた前記可変要素の前記識別属性を依存属性として有する前記可変要素を全て連続的に読むステップと、
   をさらに含む、請求項３に記載の方法。
5. 前記ツリーを部分的にトラバースする各工程は、デシジョン・ポイントを処理した後、前記ユーザの主導でストップされる、請求項１乃至４のいずれか１項に記載の方法。
6. 前記資産は、構造的言語として前記再利用可能な資産の仕様（ＲＡＳ）を用いて記述されている、請求項１乃至５のいずれか１項に記載の方法。
7. 前記依存属性は、前記ＲＡＳの「ｒｅｆｅｒｅｎｃｅ」属性である、請求項６に記載の方法。
8. 前記ユーザが提示するステップ、前記コンピュータが前記ユーザに提示するステップ、および前記コンピュータが前記ユーザから収集するステップは、グラフィカル・ユーザ・インターフェースを介して行われる、請求項１乃至７のいずれか１項に記載の方法。
9. 前記対応する資産デシジョン・ツリーの各デシジョン・ポイントに関して、識別属性と、前記資産デシジョン・ツリーにおいて前記デシジョン・ポイントが依存する要素の前記識別属性を含んだ依存属性（ｒｅｆｅｒｅｎｃｅ）と、を備えた前記要素を含む資産の記述（ガイド付き資産）を作成する初期ステップをさらに含む、請求項１乃至８のいずれか１項に記載の方法。
10. 前記ユーザから変更を収集する（４３０）前記ステップが、前記可変要素の前記バリアント要素全ての中から、少なくとも１つのバリアント要素を選択するステップを含む、請求項１乃至９のいずれか１項に記載の方法。
11. 前記ユーザから変更を収集する（４３０）前記ステップが、前記ユーザから新しいバリアント要素と付随するコード要素とを収集するステップを含む、請求項１乃至１０のいずれか１項に記載の方法。
12. 前記デシジョン・ツリーの前記トラバースを完了後、カスタマイズされた資産を作成するべく、前記変更された資産の記述を前記資産の前記内容に適用するステップをさらに含む、請求項１乃至１１のいずれか１項に記載の方法。
13. コンピュータ・プログラム製品であって、前記プログラムがコンピュータ上で実行されると請求項１乃至１２のいずれか１項による方法の前記ステップを実行するプログラミング・コード命令を含む、コンピュータ・プログラム製品。
14. 請求項１乃至１２のいずれか１項による方法を実行するようになっている手段を含む、システム。

Images