【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般にはコラボレーティブワーク（共同作業）に対する自動化された支援の分野に関し、特に、既存のコンポーネントからカスタムシステムを構成するタスクを支援する装置に関する。

【０００２】

【従来の技術】共同作業に対する自動化された支援に関する一般的な説明に関しては、LGTerveen, "An Overv
iew of Human-Computer Collaboration", Knowledge Ba
sed Systems, Special Issue on Human-Computer Colla
boration, 1995, を参照されたい。 この種の支援は、以下の３つのアプローチに大別される： アクティビティベース（Activity-based）のアプローチは、実行されなければならないアクション、アクション間のリレーションシップ（関係）、及びアクションのコミットメントを含むワークグループアクティビティに関するあらわな（エクスプリシットな）計算表現に基づいている。 計算機による支援システムは、共同作業のストラクチャを管理する目的で、例えば完了への進捗をモニタする、備忘録を出す、及びある時点で法律上のアクションを指示する、などの方法によって、上記アクティビティ表現を利用する。 この種のアプローチに関しては、Flores, F.,
Graves, M., Hartfield, B., and Winograd, T., "Comp
uter Systems and the Designof Organizatinal Intera
ction", ACM Transactions on Office Information Sys
tems, 6,2(1988), 153-172; Kaplan, SM, Tolon, W.
J., Bogia, DP, and Bignoli, C., "Flexible, Activ
e Support for Collaborative Work with Conversation
Builder", In Proc. of CSCW'92, ACM, NY, 1992, p
p.378-385; あるいは Medina-Mora, R., Winograd, T.,
Flores, R., and Flores, F., "The Action Workflow
Approach to Workflow Management Technology", In Pr
oc. of CSCW'92, ACM, NY, 1992, pp.281-288 に記載されている。

【０００３】アーティファクトベース（Artifact-base
d）のアプローチは、グループワークの一部として生成されて操作されるアーティファクト、すなわちワークプロダクト、及びその生成及び使用を支配する規則に係るコラボレーションをオーガナイズする。 この種のアプローチに関しては、Fischer, G., Grudin, J., Lemke, A.
C., McCall, R., Ostwald, J., Reeves, BN, and Shi
pman, F., "SupportingIndirect, Collaborative Desig
n with Integrated Knowledge-Based Design Environme
nts", Human Computer Interaction, 7(1992); Reeves,
B. and Shipman, F., "Supporting Communication bet
ween Designers with Artifact-CenteredEvolving Info
rmation Spaces", In Proc. of CSCW'92, ACM, NY, 1
992, pp.394-401;あるいは Wroblewski, DA, Hill,
WC, McCandless, T., "DETENTE:Practical Support f
or Practical Action", In Proc. of CHI'91, ACM, N.
Y.,1991, pp.195-202, に記載されている。 この種のシステムにおいては、アクティビティはエクスプリシットには表現されない。 なぜなら、”プラクティカルなアクション”の性質により、ワークの進行を、アプリオリに正確に予測することが不可能になるからである。 計算支援システムは、セットアクティビティストラクチャをほとんどあるいは全く利用せず、代わりにワークプロダクトに関連してオーガナイズされたコラボレーションの形態、例えばコンポーネント及びアーティファクトライブラリへのアクセスの管理する、アーティファクトを生成し、利用し、共有するためのツールの提供、などの調停を行なう。

【０００４】ツールキットベース（Toolkit-based）のアプローチは、ユーザが、希望されるどのような種類のコラボレーティブシステムでも構成することが可能となるようなツールキットを提供する。

【０００５】最もよく知られているアクティビティベースのアプローチは、Winograd、Flores、及びその同僚達による言語／アクションパースペクティブであり、それは、ザ・コーディネータ（The Coordinator）及びそれ以降のシステムとして用いられている。 これらのシステムは、要求、契約、提案、及び逆提案等の共通のタイプのアクションを解析し、これらのアクションを互いに結び付けているコミットメントのパターンを識別する。 その後、ワークグループがアクション及びコミットメントをエクスプリシットにしてそれらを管理することを可能にするようなシステムが設計される。

【０００６】ツールキットベースのシステムの一例は、
Tom Malone及び彼の同僚によるオーバル（Oval）システムであり、Malone, TW, Lai, KY, and Fry, C., "E
xperiments with Oval: A Radically Tailorable Tool
for Collaborative Work", In Proc. of CSCW'92, ACM,
NY, 1992, pp.289-297, に記載されている。 オーバルは、４つのコラボレーティブシステム、すなわちザ・
コーディネータ及び３つのアーティファクトベースのシステムであるｇＩＢＩＳ、ロータスノーツ（Lotus Note
s）、及びインフォメーションレンズ（Information Len
s）、をインプリメントするために用いられてきている。 このようなフレキシビリティを可能にするオーバルの２つのキーとなる側面は、セミストラクチャードオブジェクトの表現設定及びルールメカニズムである。 オーバルは、アクティビティを含む関連するあらゆるものを表現するためにオブジェクトの生成を可能にし、ルールはオブジェクトがどのように処理されるべきかを規定するように表現され得る。 ツールキットベースの別の例は、Kaplan, SM, Tolon, WJ, Bogia, DP, and Bi
gnoli, C., "Flexible, Active Support for Collabora
tive Work with ConversationBuilder", In Proc. of C
SCW'92, ACM, NY, 1992, pp.378-385, に記載されたC
onversationBuilder（カンバセーションビルダー）である。 カンバセーションビルダーは言語／アクションという伝統に基づくものであり、シンクロナスコラボレーションを支援するものである。

【０００７】アーティファクトベースのシステムには、
コロラド大（the University of Colorado）のGerhard
Fischer及びその同僚によって開発され、Fischerによる前掲の参照文献に記載された、ドメインオリエンテッドな設計環境が含まれる。 これらのシステムは、非同期のアーティファクトベースのコラボレーション、及びユーザがアーティファクトを構成する環境に対するインテリジェント設計アシスタンス及びコラボレーション支援の統合に集中している。 これらのシステムは、”萌芽＋発展＋再萌芽”（seed+evolution+re-seeding）モデルを提示することによって、システムに対して、利用を通じての時間発展の手段も提供する。

【０００８】この種のシステムの別の例は、LocheedでのMark及び彼の同僚らによるコメット（COMET）システムである。 コメットは、コミットメントベース（commit
ment-based）の設計のアイデアに基づいている。 この設計には、既存の設計モジュールの再利用−スペシャリゼーション及びモディフィケーション−が含まれており、
現在の設計決定を過去の決定に基づいて導く、という目標を有している。 そのため、既存のモジュールに対する最小の変更しか必要としない。 モジュールのコミットメントは、設計に包含されるために充足されなければならない束縛条件である。 設計プロセスは非常にインタラクティブである。 設計者は、自らの要求に”近い”モジュールを配置し、必要に応じて（制限された設計言語を用いて）そのモジュールに対する変更を規定し、システムが修正された記述を充足する既存のモジュールを読み出し、その後に設計者がモジュールを設計に組み込む。 この際、システムは、全てのモジュールに関するコミットメントを充足させるように支援する。 この詳細に関しては、W. Mark, S. Tyler, J. McGuire, J. Schlossberg,
"Commiment-Based Software Development", IEEE Tran
sactions on Software Engineering, 1992, を参照。

【０００９】

【発明が解決しようとする課題】これらアーティファクトベースのシステムは著しい進歩を遂げているものの、
この種のシステムへのユーザインターフェースが問題として残っている。 第一に、ユーザは、自らがディスプレイ上に必要とするアーティファクトに関する情報を見ることができることが要求される。 アーティファクトに係る情報の可視化（ビジュアリゼーション）に関しては改良されることが必要であり、同時にビジュアリゼーションと情報との関係がよりフレキシブルにならなければならない。 第二に、ユーザが、アーティファクトに係る広大かつ複雑なスペースを容易に検索できることが必須である。 第三に、ユーザは、構成中のアーティファクトにおける変更の結果に係る即時的なビジュアルフィードバックを必要とする。 第四に、ユーザは、新たなアーティファクトを構成する際に、問題点及び係争中の事項の追跡を行なうためのよりよい方法を必要としている。

【００１０】

【課題を解決するための手段】本発明に係るアーティファクトベースシステムにおいては、アーティファクトに係る情報の改良されたビジュアリゼーションをユーザに提供し、アーティファクト構成とビジュアリゼーション及び検索とを統合し、即時ビジュアルフィードバックを有するシステム依存関係メンテナンスを提供し、さらにビジュアリゼーションを調整することが可能でユーザによって必要とされる情報をユーザによって望まれている方式で表示させられるシステムをユーザに提供することによって、従来技法に係るシステムにおける問題点が解決される。

【００１１】本発明に係るアーティファクトベースシステムは、それ自体が複雑なシステムであるような既存のアーティファクトから複雑なシステムを構成するために用いられる。 本発明に係るシステムは、既存の利用可能な全てのアーティファクトとアーティファクト間の関係を規定するルールの組とに係る固定データベースを含んでいる。 本発明に係るアーティファクトベースシステムのユーザは、２つの表示領域を持つディスプレイを有している。 一方の領域には既存のアーティファクトを表現するグラフが表示される。 他方の領域には、構成中のシステムに現時点で含まれているアーティファクトを表現するグラフが表示される。 第一のグラフを生成するために、ユーザは、システムを構成するために必要とされる種類のアーティファクトに関して前記固定データベースを検索する。 検索結果は既存のアーティファクト領域に表示される。

【００１２】構成中のシステムにアーティファクトを追加するために、ユーザは、第一表示領域内のグラフにおけるアーティファクトを選択する。 選択されたアーティファクトを表現しているグラフは、第二の領域内のグラフに付加される。 追加されたアーティファクトが他のアーティファクトを必要とする、ということをルールが指示している場合には、これらのアーティファクトが自動的にグラフに追加される。 ルールが、第二の領域に対するあらゆる付加が本来そこに存在していたものとコンパチブルではない、ということを指示した場合には、グラフのコンパチブルではない部分がディスプレイ上で指示される。 システムの構成が完了すると、ユーザはこの新たなシステムを固定データベースに追加することが可能になる。

【００１３】ノード形状、色彩、線幅、パターン及びフォントタイプ等のグラフのビジュアルな側面は、グラフにおけるアーティファクトの属性を表現するために用いられる。 ユーザがノードカラーなどのビジュアルな側面に対して属性をマッピングし、さらに属性の値をビジュアルな側面の値に対してマッピングすることを可能にするマッピングエディタによって、システムのフレキシビリティが増大させられている。

【００１４】本発明に係る装置及び方法の他の目的及び利点は、以下の発明の実施の形態における記述によって当業者に対して明らかとなる。

【００１５】

【発明の実施の形態】以下の実施例の説明においては、
第一に本発明の望ましい実施例の根底に存在するアーティファクト構成のモデルが提示され、その後、前記望ましい実施例の概要が説明される。 次に、電子電話交換機向けの機能の組を規定する目的で用いられる本発明の望ましい実施例の一例に関する詳細な説明がなされ、最後に、本発明の望ましい実施例のインプリメンテーションの詳細が提供される。 本発明の望ましい実施例には、当該実施例によって生成される表示を修正するためのツールも含まれる。 これらのツールに関しても、概要及びその詳細が説明される。

【００１６】図１は、本発明に係るアーティファクト構成モデル１０１を示している。 これは、支援システムが担うべき支援及び適切な役割を必要とする中心的タスクを規定する”規定（プリスクリプティブ）”モデルである。 図１においては、四角の箱はシステムコンポーネントを表現しており、楕円はシステムタスクを表現している。 矢印は情報の流れを示している。

【００１７】ここでは、以下の３つのタスクが注目されている： 顧客の要求を充足するオブジェクトを”配置する”こと、配置されたコンポーネントからアーティファクトを”構成する”こと、及び、アーティファクトが構成される際に依存関係を管理すること。 このモデルは、ワーク管理及び開発（矢印１０５、１２７、１２
９）を規定する（要求を充足するコンポーネントが配置され得ない場合には、その要求を記述するワークリクエストが生成され、結果として充足させるコンポーネントの開発が行なわれる）が、図１に示されているシステムはこれらのタスクをサポートしないため、以下には記述されない。

【００１８】このモデルは、各々のタスクを支援する際にシステムが担うべき役割を規定する。 このモデルのコンポーネントには、アーティファクトが選択されるパレット１０３、構成中のシステムがアセンブルされるワークエリア１１３、及びパレット１０３において規定されたアーティファクトに関する情報１３３とアーティファクト間の依存関係に関する情報１３５とを含むプロダクトデータベース１３１が含まれている。 以下、各々のタスクが簡潔に説明される。

【００１９】”パレット”の概念は、市販されているドローイングツールからリサーチシステムまでの構成キットにおいて公知である。 パレットは、しばしばウィンドウ内のアイコンリストとしての、ユーザが利用可能なドメインにおける基本的なコンポーネントを構成しており、ユーザの要求を充足するコンポーネントを配置することを可能にしている。 本発明に係るモデルは特定のプレゼンテーションメソッドに付されているものではないが、コンポーネントを直接ブラウズする方法及び記述を規定することによってスペース検索を行なう方法の双方はサポートされているべきである。 加えて、巨大かつ成長しつつあるプロダクトデータベース１３１に関しては、全ての依存関係が知られるとは非常に考えにくい。
データベース１３１をブラウズしながら、ユーザはそこに与えられている情報のうちのあるものが既に陳腐化してしまっていることを理解する。 データベースをアップデートするためにデータベースを発展させる方法がユーザに対してサポートされているべきである（矢印１２
１）。

【００２０】顧客の要求を充足するオブジェクトが配置される場合には、それらはシステムワークエリア内に含まれている発展中のアーティファクトに”マージ”されなければならない（矢印１１１）。 オブジェクトが追加されると、システムは、システムタスク１１７及び矢印１１５及び１２３によって示されているように、アーティファクトが完全で自己無撞着であることを保証するために、ドメインオブジェクト間の”依存関係”を”管理”する。 ユーザが、例えばフォームに記入することなどの非プログラミング修正によってオブジェクトを調整することが必要になる場合がある。 ユーザは、簡潔な注から構造化された理論的根拠までの範囲にわたる情報を含ませるためにアーティファクトに注釈を付けることを望む場合がある。 アーティファクトが完成した場合には、ユーザはそれを”公開”する、すなわちそれをプロダクトデータベース１３１に追加する（矢印１１９）ことが可能でなければならない。

【００２１】依存関係を管理することは共同ワークの要である。 よって、以下に本発明に係るモデルにおいて規定されている依存関係のタイプを簡潔に説明する。 依存関係の最も基本的なタイプは、例えばあるコンポーネントが第二のコンポーネントとはコンパチブルではなく、
さらに第三のコンポーネントを必要とする、というようなコンポーネント間のものである。 第二の依存関係のタイプは、人間に係るコンポーネントのタイプである。 例えば、コンポーネントは、全ての修正を認可しなければならない”オーナー”を有している場合がある。 オーナーシップ情報は、アーティファクトを構成しているユーザにとって有用である場合がある。 このようなユーザはコンポーネントを修正しようと欲するがゆえにオーナーシップ情報を必要とし、また、オーナーの世評に基づいてコンポーネントを選択しようと欲する場合もある（社会的フィルタリングの一形態）。 最後に、コンポーネントに関連する、スケジュール化されたアクティビティに関する知識、例えばメンテナンスあるいは新たな開発ワーク、が、システムが完成すべき時点でそのコンポーネントが利用可能であるか否かを決定する際に必要になる場合がある。

【００２２】本発明の望ましい実施例の概要：図２図２
は、本発明の望ましい実施例の高位ブロック図である。
アーティファクト構成システム２０１は、固定情報データベースをストアするコンポーネント、グラフィカルディスプレイを生成するコンポーネント、対話的ユーザ入力を受信するコンポーネント、及びデータベース内の情報とユーザ入力とに応答してグラフィカルディスプレイを生成し、かつデータベースを修正する処理コンポーネントを含むあらゆるコンピュータシステムにおいてインプリメントされ得る。

【００２３】図２は、アーティファクト構成システム２
０１のメインコンポーネント及び全体としての情報の流れを示している。 このシステム２０１のアーキテクチャは、２つのデータベース２０２及び２２１、２つのメインディスプレイウィンドウ２１１及び２１５、及び２つの処理コンポーネント２０９及び２２３から構成されている。 矢印は情報の流れを示している。 括弧内の番号は、図１における対応するコンポーネントを示している。

【００２４】固定データベース２０２は、特定のドメインに関するロングターム情報を含んでいる。 これは、少なくとも３つのタイプの情報を含んでいる： ・コンポーネント２０３： これらは、システムがアセンブルされることになるドメインの”プリミティブアーティファクト”である ・ストラクチャ２０５： これらはこのドメインの”複合アーティファクト”である ・ルール２０７： ルールは、コンポーネントの組から”合法的な”ストラクチャが如何にして構成されるかを規定する。 例えば、２つのコンパチブルではないコンポーネントがあるストラクチャに対して追加された場合には、ルールはこのインコンパチビリティをマークする。 これらのコンポーネントのうちの一方が後に削除された場合には、別のルールが前記インコンパチビリティを削除する。 第二のコンポーネントを必要とするコンポーネントがあるストラクチャに対して追加される場合には、その必要とされるコンポーネントも自動的に追加される。 データベース２０２内の全てのストラクチャ２０
５は、”合法性”に関して全てチェック済みである。 全ての”非合法性”はデータベース２０２内で記録されている。

【００２５】ワーキングデータベース２２１は、現時点で構成中のシステムを表現するワーキングストラクチャ２２７を含んでいる。 サーチエリア２１１は、固定データベース２０２の内容の可視化を提供するディスプレイウィンドウである。 処理コンポーネント２ ２０９は、
この可視化を計算する。 ユーザは、ワーキングストラクチャに追加したいコンポーネントあるいはストラクチャをデータベース２０２から検索する。 ユーザは、表示される情報をフィルタリングし、希望するように表示させる種々の操作を起動することが可能である。 検索が終了すると、検索によって見い出されたコンポーネントあるいはストラクチャを表現するグラフ２１３がサーチエリア２１１内に現れる。

【００２６】ユーザがコンポーネントあるいはストラクチャをワーキングストラクチャ２１１に追加しようとする場合には、ユーザはそのコンポーネントあるいはストラクチャを表現しているグラフを指示してサーチエリア２１１から選択する。 このことによって、追加されたコンポーネントと元のコンポーネントとの間の衝突を検出する目的で必要とされるコンポーネントの全てがワーキングストラクチャ２２７に対して追加されていることを保証する処理コンポーネント３ ２２３に対してトリガがかけられる。

【００２７】ワークエリア２１５は、ワーキングデータベース２２１の内容を表現するグラフ２１７を表示するディスプレイウィンドウである。 処理コンポーネント２
２０９は、再び可視化を計算する。 ユーザは、（ボタン２１６によって表現された）種々の操作をワークエリア２１５の内容に対して起動することができる。 あるものは、提供される情報の表示を調整する。 他のものは、
ワーキングストラクチャ２２７における情報を修正し、
それが処理コンポーネント３ ２２３を再びトリガする。 処理コンポーネント３ ２２３は、ワーキングストラクチャ２２７が変更される毎にその”合法性”を保証するルールを適用する。

【００２８】本発明の望ましい実施例における動作の概要 アーティファクト構成システム２０１は、通常、標準的なアーティファクトの組からアーティファクトを組み合わせることによって顧客の特注に対してシステムが”カスタマイズされる”場合に用いられる。 標準的なアーティファクトの組は、固定データベース２０２内に含まれている。 システム２０１のユーザの第一のタスクは、固定データベース２０２内で利用可能であるものを決定することである。 ユーザは、データベース２０２内のコンポーネント２０３及びストラクチャ２０５を検索するあるいはブラウズすることによってこのことを実行する。
検索あるいはブラウズ操作によって見い出されたコンポーネントあるいはストラクチャを表現するデータストラクチャは処理コンポーネント２ ２０９に対して供給され、処理コンポーネント２ ２０９はサーチエリア２１
１内のコンポーネント及びストラクチャを表現するグラフ２１３を生成する。 ユーザは、操作を規定する、マウスによって活性化される”ボタン”２１２及びボタンが選択された場合に現れるメニューによって、検索及び／
あるいはブラウズを制御する。

【００２９】ユーザが、構成中のシステムに含めたいと欲するアーティファクトをサーチエリア２１１に見い出した場合には、ユーザは、サーチエリア２１１内のアーティファクトを表現しているノードを選択するためにマウスなどのポインティングデバイスを利用し、選択されたノードによって表現されるアーティファクトが構成中のシステム内に含められることを規定するボタン２１２
を活性化する。 このことがなされると、選択されたノードによって表現されるアーティファクトに係るノード及びそのアーティファクトによって必要とされる全てのアーティファクトがワークエリア２１５内のグラフ２１７
に対して追加される。

【００３０】システム２０１の処理コンポーネント３
２２３は、選択されたグラフ２１３のワークエリア２１
５に対する追加に応答して、データベース２０２内のルール２０７を用いて、そのアーティファクトによって必要とされる他の全てのアーティファクト及び追加されたアーティファクトそのものがシステムに既存のアーティファクトとコンパチブルであるか否かを決定する。 他のアーティファクトが必要とされる場合には、それらは自動的に追加される。 矛盾が生じた場合には、ワークエリア２１５内のアーティファクトを表現しているグラフ２
１７が、２１９によって示されているように、このインコンパチビリティによってどのアーティファクトが影響を受けているかを指し示すように修正される。 その後、
ユーザはこのインコンパチビリティを解決するために、
必要に応じてアーティファクトを削除する。 削除によってインコンパチビリティが解決された場合には、ディスプレイはそのインコンパチビリティの表示を中止する。
システムは、ある与えられたアーティファクトが除去された場合に他のどのアーティファクトがもはや必要とされていないかを決定するために、整合性チェックを行なう。 ディスプレイはこれら不要なノードを表示し、ユーザはそれらのノードによって表現されるアーティファクトを削除あるいは保持する。

【００３１】ユーザがワークエリア２１５内のシステムに満足した場合には、そのユーザはそれらを固定データベース２０２にストアしたい旨を表現する。 このことは、処理コンポーネント２２５によってなされる。 データベース２０２においては、このシステムは他のものと同様にストラクチャ２０５となり、別のシステムを生成するために検索されたり利用されたりする。 前述されているように、ワークエリア２１５内のグラフによって表現されているシステムの修正及びそのシステムのストアは、ボタン２１６及びポインティングデバイスからの入力によって制御される。

【００３２】システム２０１のアプリケーション 本発明の望ましい実施例であるシステム２０１は、ＡＴ
＆Ｔ社製の大規模な電子電話交換機である５ＥＳＳ ^(TM)
を顧客の仕様に従ってカスタマイズするために実験的に用いられた。

【００３３】このアプリケーションにおいては、交換機をカスタマイズするために組み合わせられるプリミティブアーティファクトはフィーチャー（ｆｅａｔｕｒｅ
ｓ）である。 フィーチャーは通信における中心的な概念である。 通話転送、通話待機、及び会議通話は、顧客に対して提供される公知のフィーチャーである。 回線テストあるいはサービスオブザベーション等の他のフィーチャーが、ネットワークの操作の管理を助ける目的で電話会社によって用いられる。 フィーチャーは、顧客に一貫した機能ユニットを提供する、ソフトウエアによってインプリメントされた抽象概念であるとみなすことができる。 フィーチャーは、５ＥＳＳ交換機の製造ビジネスの全ての側面において中心的な役割を果たしている。 すなわち、開発及びテストは、フィーチャーの生成、拡張、
管理、パッケージング、及びテストの周囲に組織化されている。 開発、テスト、及び他の関連するタスクは全て本質的に複雑なものである。 加えて、この交換機の購入数の急速な増加及び顧客の要求の複雑性に対応して、フィーチャーの数及びタイプが増加している。 その一方、
フィーチャー情報を管理するシステム及びプロセスは限界に達し、フィーチャーの新たな組み合わせに対する顧客からの要求に対して迅速かつ正確に対応することがより一層困難になってきている。

【００３４】フィーチャーに係るワークを行なっている人々は、以下の特別な術語を用いる。 ・顧客デリバリ： ある顧客に対してパッケージとして組み合わせてデリバリされるフィーチャーの組 ・フィーチャー： 顧客機能の基本的ユニット ・フィーチャークラスタ： 機能的に関連しているフィーチャーよりなる群 ・オプション： フィーチャーがどのように機能するかを決定する選択肢 ・セッティング： オプションとして取りうる値と、オプションは常にデフォールトセッティングを有する ・バウンドフィーチャー： テストされてデリバリされた、全てのオプションに対するセッティングを有するフィーチャー ・ワークアイテム： フィーチャーを修正あるいは生成するために必要とされる開発ワーク ・依存性： フィーチャー、オプション及びセッティング間の拘束条件 ・アプリケーション： ５ＥＳＳ交換機が用いられる特定の方法

【００３５】顧客デリバリを規定する目的でのアーティファクト構成システム２０１の利用アーティファクト構成システム２０１が５ＥＳＳに対する顧客デリバリを規定する目的で用いられる場合には、固定データベース２
０２からのアーティファクトは、サーチエリア２１１内にグラフとして表示される。 システム２０１は、読み出されたアーティファクトが３通りに表示されることを可能にしている。 （図３に示されている）最も一般的な表示方法はフィーチャークラスタであり、各々のクラスタ内にはフィーチャーが示され、バウンドフィーチャー及び各々のフィーチャーのオプションが表示される。 第二の方法は、アプリケーション及びその基本的かつ特徴的なフィーチャーを示すものであり、第三の方法はフィーチャー及びフィーチャー間の依存性を示すものである。

【００３６】グラフ内のオブジェクトが選択され、種々のコマンドによって操作される。 コマンドのうちのあるものは前記３つの基本的な表示方法に対して適用され、
あるものは特定の表示タイプに対してのみ適用される。
全ての表示方法に対して共通であるコマンドは、例えばテキストによる記述あるいは選択された属性の表を要求することによる、特定のオブジェクトの詳細な調査を可能にする。 フィーチャーに依存した表示方法に特有のコマンドは、ユーザがフィーチャー間の新たな依存関係を規定して、製品データベースを発展させることを可能にする。

【００３７】図３を詳細に検討すると、本発明の望ましい実施例におけるサーチエリア２１１は、ユーザによる終了を可能にするボタン３０５、ユーザが前記３つの表示方法のうちの一つを選択することを可能にするボタン３０７、ユーザが検索を行なうことを望んでいることを表わすボタン３０９、及び、ユーザがエリア２１１内の選択されたアーティファクトの組をワークエリア２１５
内の開発中の製品に対して追加することを望んでいることを表わすボタン３１１を含んでいる。 ラベル３０３
は、どの表示方法が用いられているいるかを表している。 ここでは、フィーチャー及びフィーチャークラスタ３１３である。

【００３８】情報空間のサイズ及び複雑さのために、検索機能は非常に重要である。 ボタン３０９が押されると、検索メニューが現れる。 検索メニューにおいてオプションを選択すると、別の検索メニューが現れる。 このメニューの組は図４に示されている。 これらのメニューにより、グラフ内に表示されているオブジェクトをフィルタリングするために用いられる検索パターンをユーザが規定することが可能になる。 デフォールトでは、検索キーを満足しない全てのオブジェクトは淡色表示される。 ユーザは、検索キーを満足しないオブジェクトを隠すようにすることを選択することもできる。 図４に示されているように、ユーザは、検索中のアーティファクトの種類を規定することができる（メニュー４０３）。 ひとたびこれがなされると、どの種類のアーティファクトが検索されているかを表わすメニューが現れる（メニュー４０５及びメニュー４０７）。

【００３９】一般的な検索のタイプの例としては、特定のフレーズに一致する記述を有するオブジェクト、特定の個人によって所有されているフィーチャー、あるいはある顧客に対してデリバリされたフィーチャーパッケージ、などが挙げられる。 重要なフィーチャーは、検索が反復可能である、ということである。 ユーザは、各々が直前の検索の結果に対して適用される、一連の検索を規定することができる。 システムは、各々の検索を満たすオブジェクトの組を記録するデータストラクチャを管理しており、ユーザが検索空間内の以前のポイントを”バックアップ”することを可能にする。 （フィーチャークラスタ、アプリケーション、及びフィーチャー依存関係グラフ等の）”基本表示方法”は、検索空間におけるスターティングポイントとして機能する。

【００４０】サーチエリア２１３におけるユーザによるワークの目的は、ワークエリア２１５において構成されつつある顧客デリバリに対して追加されるべきオブジェクトを配置することである。 追加は、希望するオブジェクトを表現しているノードを選択するためにポインティングデバイスを利用し、選択されたオブジェクトが顧客デリバリに対して追加されるべきものであることを表わす目的で”デリバリへの追加”ボタン３１１を用いることによってなされる。 デリバリは、図３のワークエリア２１５内の指示グラフとして視覚的に表示される。 オブジェクトが顧客デリバリに対して追加されると、システムはそのオブジェクトに係る全ての依存関係を自動的に管理する。 ユーザに対する効果は、ユーザがデリバリに対して追加されるべきオブジェクトを規定すると、システムがワークエリア２１５内のグラフにおいてそのオブジェクトを表現しているノードの位置を指し示し、そのオブジェクトによって必要とされる他のオブジェクトを表現しているノードを追加し、オブジェクトを表現しているノード間で必要とされるリンクを生成し、全ての矛盾点を検索して表示する、というものである。

【００４１】ワークエリア２１５： アーティファクト生成の支援 図３のワークエリア２１５をより詳細に観測すると、ワークエリア２１５内のグラフ３２５は、現時点でワークがなされている顧客デリバリの現時点でのステータスを示すフィーチャー依存関係グラフである。 ボタンは、以下の動作を可能にする。 １． 与えられたアプリケーションにおいて要求されるフィーチャーをデリバリへ追加 ２． デリバリが固定データベース２０２に対して追加されるべきものであることを規定 ３． フィーチャーに係る結合を規定 ４． サポートされていないフィーチャーに対してサポートを付加 ５． 選択されたノードを削除 ワークエリア２１５内のデリバリのフィーチャー依存関係グラフ２１７は、フィーチャーを表現するもの及びアプリケーションを表現するものの２種類のノード、及びフィーチャー間及びアプリケーションとフィーチャーとの間の相異なった依存関係を表現する４種類のリンク、
を含んでいる。 ・必要リンクは、フィーチャーとそれが必要とする全てのフィーチャーとを接続する ・インコンパチブルリンクは、共にデリバリされ得ない２つのフィーチャーを接続する ・基本フィーチャーリンクは、アプリケーションをその基本フィーチャーに接続する及び、 ・プレミアムフィーチャーリンクは、アプリケーションをそのプレミアムフィーチャーに接続する顧客デリバリグラフ２１７における重要な慣例は、ユーザによって追加されたオブジェクトが最も左側の列に現れ、上から下への順序がオブジェクトが追加された時間的な順序を反映している、というものである。

【００４２】ワークエリア２１５は、いくつかの付加的な重要機能を実現する。 第一に、ワークエリアは、ユーザが現時点でのデリバリを再利用可能なパッケージとしてセーブすることを可能にする。 そのデリバリに係る顧客あるいはそれを生成したユーザといった情報は、パッケージと共にストアされる。 加えて、ユーザはテキストによるコメントを付加することが可能である。 これらの情報の全ては、他のユーザが将来再利用可能な関連したパッケージを検索する際に有効である。 第二に、ユーザは、現時点でのデリバリを完全に置換する、あるいは更新中のものにマージする目的で、直前のデリバリをロードすることができる。 第三に、あるフィーチャーに係る既存の全てのバウンドフィーチャーが顧客の要求を満足しない場合には、ユーザは、そのフィーチャーに関するオプション及び各々のオプションに対する設定可能な値とを表示したウィンドウを用いて、新たなバウンドフィーチャーを容易に生成することが可能である。 このウィンドウは、ボタン３２０が活性化された場合にワークエリア２１５内に現れる。 この様子は図５のウィンドウ５
０１に示されている。 ウィンドウは２つの部分を有している。 部分５０３は、フィーチャーに対して現時点でバウンドされている値を示しており、ユーザがそのうちの一つを選択することを可能にする。 あるいは、ユーザは、部分５０３において、ユーザがそのフィーチャーに対してバウンドさせたい値を示すことが可能である。 この場合には部分５０５が現れ、ユーザは新たなバウンド値を定義するために部分５０５を利用することができる。

【００４３】依存関係の管理 システム２０１は、依存関係を管理する目的で、ワーキングストラクチャ２２７及び固定データベース２０２内のコンポーネント２０３、ストラクチャ２０５、及びルール２０７を利用する。 ユーザがデリバリに追加されるべきオブジェクトを規定すると、システムはそのオブジェクトの固定データベース２０２内における表現、ワーキングストラクチャ２２７におけるデリバリの表現、及びこの新たに追加されるオブジェクトに関連する全ての依存関係を調査する。 ユーザのアクションに応答してシステムによって実行される操作には、以下のものが含まれる： ・ユーザが追加されるべきフィーチャークラスタを規定する場合には、クラスタ中の全てのフィーチャーがデリバリに対して追加される。 ・ユーザが追加されるべきアプリケーションを規定する場合には、そのアプリケーションに係る全ての基本フィーチャーがデリバリに対して追加される。 ・ユーザが追加されるべきフィーチャーを規定する場合には、システムはそのフィーチャーに対するデフォールトバウンドフィーチャーを読み出してそれを代わりに追加する。 （フィーチャーではなくバウンドフィーチャーが顧客に対してデリバリされることに留意されたい。）
しかしながら、ユーザは、いつの時点においても、相異なった、デフォールトフィーチャーではないフィーチャーを規定したり、デリバリ内のフィーチャーに関する新たなバウンドフィーチャーを生成することも可能である。 ・フィーチャーが、ユーザの要求あるいはシステムによる依存関係管理のいずれかによって追加される場合には、システムは、そのフィーチャーに係る全ての必要とされるフィーチャーが、それらが既に存在していない場合にはそれらを追加することによって、デリバリ内に存在することを保証する。 ・オブジェクトが追加される場合には、システムは、そのオブジェクトとデリバリ中の他のオブジェクトとの間のあらゆる矛盾点を検出する。 ・オブジェクトが追加される際には、オブジェクトがデリバリ中に存在する理由を記録する”正当化（ジャスティフィケーション）”が生成される（例えば、そのオブジェクトはユーザによって直接追加された、あるアプリケーションの基本あるいはプレミアムフィーチャーである、他のフィーチャーによって必要とされるフィーチャーである、等々）。 ジャスティフィケーションは、グラフレイアウトの決定及び与えられたオブジェクトがグラフから削除されたか否かの決定の際に用いられる。 ・ユーザがオブジェクトを削除する場合には、システムは、残存するオブジェクトに関する影響を決定するためにジャスティフィケーションストラクチャを調査する。
第一に、オブジェクトを削除することにより、それらに関するジャスティフィケーションが”サポート無”になる。 システムは、これらのオブジェクトの表示を変更することによってこの事実を公告するが、それらを削除するかあるいはデリバリ中に残存させておくかの決定はユーザに委ねられている。 第二に、オブジェクトを削除することによって矛盾点が解決される場合があり、そのことはシステムによって視覚的に表示される。 以上をまとめると、システムは、デリバリが完成したこと、及びワーキングストラクチャ２２７あるいは固定データベース２０２におけるあらゆる矛盾点がそれらが解決されるまで指摘されつづけること、を保証する。

【００４４】オブジェクト集中情報デリバリ システム２０１の中心的なフィーチャーは、その情報デリバリに係るオブジェクト集中メソッドである。 システム２０１は、ワークオブジェクトそれ自体の表示上で、
タスク及びコラボレーションに関連する情報をエンコードする。 その目的は、個別の文字情報あるいはやるべきことのリストを調べるように強制させるのではなく、ユーザの通常のワークオブジェクトとの関連を維持しながらユーザをタスクに留まらせるようにすることである。
オブジェクト集中アプローチは、システムによって計算された情報のデリバリを行ない、かつ、ユーザが、ユーザ自身の現時点でのタスクに係るプロパティに集中する目的でオブジェクト表示を調節することを可能にする。

【００４５】第一に、システムが顧客デリバリのユーザによる修正に応答して依存関係を管理する際に、システムは、オブジェクトを追加し、オブジェクト間の関係を追加し、あるいはオブジェクト状況情報を修正しなければならない場合がある。 これらの変更は、オブジェクトのコンフィグレーション、及びノードカラー及び背景パターン、リンクカラー、及びフォント選択などの表示プロパティの双方において、全てデリバリグラフの視覚表示に反映される。

【００４６】第二に、ワークオブジェクトは、数多くの関連する、本質的に動的なドメイン情報を有しており、
それらの相異なったサブセットは相異なったタスクに関連している。 システム２０１における処理コンポーネント２ ２０９は、オブジェクトのどのプロパティが表示されるべきか、及びそれらがどのように表示されるべきかを規定するデフォールトマッピングルールの組を適用する。 例えば、デリバリグラフにおいて、矛盾するオブジェクトは赤色で表示され、特別な背景パターンが、複数個のバウンドフィーチャーが規定されているフィーチャーを指し示す。 最も重要なことは、ユーザが、表示されるべき相異なったプロパティ及び／あるいはそれらを表示する相異なったリソースを選択することによってこれらのマッピングを調節することを可能にするエディタが提供されていることである。

【００４７】シナリオ 次に、顧客デリバリを構成する際に関与している共同ワークをシステム２０１の機能がどのようにサポートするかを詳細に記述したシナリオが提示される。 このシナリオの細部は作為的なものであるが、実行されるワーク及びシステムがそれをサポートする方法は正確である。 ここで、”ニューヨーロッパテルコ”会社から要求文書が受信され、トム及びキャシーがリンダが指揮を取っているプロジェクトチームに配属されたと仮定する。 ここでは、グループワークの４つの段階を考慮する。 まず、リンダがこのプロジェクトに関する基本的な顧客デリバリを生成する。 次に、キャシーが、彼女が割り当てられた要求に応えるために基本顧客デリバリを生成する。 その後、トムが同様のことを行なう。 最後に、キャシーが彼らの個別のフィーチャーリストを互いにマージして統一された顧客デリバリを生成する。

【００４８】１． リンダが基本顧客デリバリを生成する リンダは、まず、このデリバリ、”ニューヨーロッパテルコ”、に対する顧客を規定する。 次いで、デリバリされるべきアプリケーション（すなわち、交換機が将来用いられる用法）がインテリジェントネットワーク、すなわちＩＮ、であることを決定し、ＩＮアプリケーションに対する顧客デリバリを見い出し、見い出したものをブラウズするために、固定データベース２０２にストアされた以前の顧客デリバリを検索する目的でサーチエリア２１５を利用する。 しかしながら、彼女は再利用するに適したデリバリを見い出さず、デリバリワークエリア内のＩＮアプリケーションを規定するだけとなる。 ＩＮアプリケーションを規定する際には、システムは、ＩＮアプリケーションの基本フィーチャーを表現するノード及びその基本フィーチャーによって要求されるあらゆるフィーチャーを表現するノードを含むグラフをワークエリア２１５内に作製する。 この例の場合には、”外国における電圧のテスト（Foreign Voltage Tests）”というフィーチャーが複数個の別のフィーチャーを要求するため、これらのフィーチャーを表現するノードが自動的に追加される。 その後、リンダは、この顧客デリバリを固定データベース２０２に”ニューヨーロッパテルコ１−
９４ベース”としてセーブする。

【００４９】２． キャシーが割り当てられた要求に応じる キャシーは、リンダによって生成されたベース顧客デリバリをワークエリア２１５へロードすることから開始する。 彼女に対する要求を読むことにより、顧客がＩＳＤ
Ｎサービスを欲していることが明らかになる。 それゆえ、彼女は、サーチエリア２１１を、記述中に”ＩＳＤ
Ｎ”という文字列を含む全てのフィーチャーを検索するために用いる。これらのフィーチャーを表現しているグラフがサーチエリア２１１に表示され、キャシーはこれらをブラウズし、いくつかのものに対する記述を詠み、
それらを全てワークエリア２１５内の顧客デリバリに追加することを決定する。 しかしながら、２つのフィーチャー、”ダイバージョンサービスの呼び出し（Call Div
ersion Services）”及び”オフィストラフィックフロー測定（Office Traffic Flow Measurements）”、が、
他のフィーチャーと矛盾することがわかる。 システムはこのことを検出し、これら２つのフィーチャーを表現しているノードを赤色に変え、この矛盾を表示するためにノード間にリンクを追加する（赤色に色を変えるのは、
矛盾を表示するためのシステムデフォールトの方式である）。 双方の記述を読んだ後、キャシーは”ダイバージョンサービスの呼び出し”フィーチャーをデリバリから削除し、システムは、”オフィストラフィックフロー測定”フィーチャーの表示を、それが現在では無撞着であることを表わすために更新する。 キャシーは、彼女のワークを”ニューヨーロッパテルコ１−９４キャシー”としてセーブする。

【００５０】３． トムが割り当てられた要求に応じる トムも、リンダによって生成されたベース顧客デリバリをワークエリア２１５へロードすることから開始する。
（彼は、キャシーによる顧客デリバリをロードしてそれに対してワークを行なうことも可能である。ただし、ここでは、キャシーとトムとが並行してワークを行なうと仮定する。）割り当てられた要求を読んで、トムは、彼のグループが過去に同様の要求に応じたことを思い出す。 彼は友人のフランクが関わっていたことを知っているため、フランクによって生成された顧客デリバリを検索する。 彼はそのうちの一つを見い出し、対応するグラフがサーチエリア２１１内に表示される。 その顧客デリバリのフィーチャーをブラウズすることにより、彼は、
それらのうちの幾つかのものが彼に対して割り当てられた要求を満たすために直接適用できることを見い出し、
それらを選択してワークエリア２１５内のベース顧客デリバリに追加する。 作業が終了すると、トムは自らのワークを”ニューヨーロッパテルコ１−９４トム”としてセーブする。

【００５１】４． リンダが統合された顧客デリバリを生成する リンダは、まず、キャシーにより顧客デリバリをワークエリア２１５にロードしてそれにトムによる顧客デリバリをマージする。 システムは、マージを行なう際に、他のフィーチャーが要求されていないか、フィーチャー間の衝突はないか、さらに、トムとキャシーが同一のフィーチャーにおいて相異なったバウンドオプションを規定していないか、をチェックする。 この場合は、トムとキャシーは”サービスオブザベーション（Service Observ
ation）”及び”マニュアルコード制御（Manual Code C
ontrols）”の双方に相異なったバウンドフィーチャーを規定しており、システムは、これらのフィーチャーを表現しているグラフノードの背景パターンを変更する（これは、システムデフォールトである）。各々のフィーチャーに対して、リンダは図５に示されているようなウィンドウをアクセスし、各々のフィーチャーに対して単一のバウンドフィーチャーを選択してこの問題を解決する。リンダは、ワークエリア２１５内のグラフがトムによって規定されたフィーチャーとキャシーによって規定されたフィーチャーとの間の矛盾を示していることに気付く。これらのフィーチャーを詳細に調べた後、彼女にはこの矛盾に対して何をなすべきかが明確ではなく、
トムとキャシーと話し合うことを決定する。 矛盾に関する情報がワーキングストラクチャ２２７及び／あるいは固定データベース２０２に保持されており、かつデリバリのフィーチャー依存関係グラフが表示される度に表示されるため、リンダがその矛盾を見失う危険性はない。
最後に、リンダは、このデリバリに対する”再テストのみ（Retest-Only）”及び”拡張（Extension）”リストを調べようとする。 システムはこの情報を構成プロセスを通じて計算してきている。 しかしながら、デフォールトでは表示されない。 リンダは、アーティファクト属性をディスプレイリソースにマッピングし、”フィーチャーリスト”属性を選択し、各々のフィーチャーが掲載されているフィーチャーリストを識別するために用いられるべきフォントカラーを規定するマッピングエディタを起動し、”再テストのみ”フィーチャーが白色で、”拡張”フィーチャーが緑色で、それぞれ表示されるように規定する。 デリバリを調べた後、リンダは２つの相異なったフィーチャーリストに現れるフィーチャーをリストしたリポートを生成する。 図３のワークエリア２１５
は、この時点でのデリバリを表示している。

【００５２】インプリメンテーションの詳細 インプリメンテーションの詳細に係る以下の説明においては、まず、本発明の望ましい実施例のインプリメンテーションの概要が提供され、次いで本発明の望ましい実施例において用いられているＣＬＡＳＳＩＣにおける概念的階層構造が記述され、その後、本発明の望ましい実施例における無撞着性のチェックの詳細が提供され、最後に本発明の望ましい実施例におけるマッピングエディタの詳細が記述される。

【００５３】インプリメンテーションの概要： 図７ 本発明に係るシステム２０１の望ましい実施例は、Ｃプログラミング言語及びＸウィンドウシステムを用いてインプリメントされ、ＵＮＩＸオペレーティングシステム（ＵＮＩＸはＸオープン（Ｘ ＯＰＥＮ）の登録商標である）を用いるワークステーション上で実行される。 これには、Ｃライブラリとして提供される３つのテクノロジーが含まれる： ・ＣＬＡＳＳＩＣは、一般クラス及び特定のインスタンスの双方の構造化されたオブジェクトを表現するため及びオブジェクトを階層的に配列するための手段、及び単純な前方結合則を含む複数個の推論技法を含むフレームベースの表現言語である。 その詳細に関しては、Brachm
an, RJ, McGuinness, DL, Patel-Schneider, PF,
Resnick, LA, and Borgida, A., "Living with CLAS
SIC: Whenand How to Use a KL-ONE-Like Language", i
n Formal Aspects of Semantic Networks, J. Sowa, E
d., Morgan-Kauffman(1990)を参照されたい。 ・Ｘｔｅｎｔは、Ｘウィンドウベースのグラフィカルユーザインターフェースを開発するためのインターフェーススペシフィケーション言語である。 詳細に関しては、
Blewett, D., Anderson, S., Kilduff, M., Udovic,
S., Wish, M., "X Widget Based Software Tools for U
NIX", In Proc. of 1992 USENIX Conference, 1992, p
p.111-123を参照されたい。 ・ｌｉｂｇｒａｐｈグラフパッケージは、指示属性及び未指示属性を有するグラフを表現して操作するために用いられる。 North, SC, and Vo, KP, "Dictionary a
nd Graph Libraries", in Winter USENIX Conference P
roceedings, 1993, pp.1-11を参照されたい。 図７は、
コンポーネント間の関係を示している。 インプリメンテーション７０１は、処理コンポーネント２０９、２２
３、２２５をインプリメントしているＣコード７０３を含んでいる。 このコードは、ＣＬＡＳＳＩＣ７０５、ｌ
ｉｂｇｒａｐｈ７０９、及びＸｔｅｎｔ７１９からのライブラリルーチンの起動を含んでいる。 フィーチャーに関する実際のデータは、ＣＬＡＳＳＩＣデータファイル７０７において維持されている。 インプリメンテーション２０１が実行されている場合には、ＣＬＡＳＳＩＣ
は、２つのデータベース、すなわち固定データベース２
０２をインプリメントする固定ＣＬＡＳＳＩＣデータベース７０４とワーキングデータベース２２１をインプリメントするワーキングＣＬＡＳＳＩＣデータベース７０
６、をメモリ内に実現するために、ＣＬＡＳＳＩＣデータファイル７０７内の情報を利用する。

【００５４】Ｃコード７０３のコンポーネントは、３つのグラフ、すなわち固定データベース７０４中のオブジェクトの全てを示すグラフであるポテンシャルグラフ７
２５、サーチエリア２１１に現時点で表示されているグラフを表わすサーチグラフ２２７、及びワーキングストラクチャ７２７に対応するグラフを表わすワーキンググラフ７２９、を生成するために、データベース７０４及びデータベース７０６から情報を引き出し、ｌｉｂｇｒ
ａｐｈ７０９からのライブラリルーチンを利用する。 当然このグラフはワークエリア２１５に表示される。 直前の検索結果７２３は、直前の検索において見い出されたＣＬＡＳＳＩＣオブジェクトのリストをストアしており、それによって、ユーザがサーチエリア２１１での検索から得られたグラフを迅速に再表示することを可能にしている。

【００５５】サーチエリア２１１及びワークエリア２１
５内のグラフの表示、及びそれらグラフ及び全体の表示の他の部分とのユーザのやり取りは、Ｘｔｅｎｔライブラリルーチンによって取り扱われる。 Ｘウィンドウにおいては、グラフノード及びリンク及びボタン等のディスプレイコンポーネントは、ウィジェットによって表現される。 ウィジェットは、ディスプレイ７１３におけるコンポーネントの振る舞い、及びこれらのコンポーネントがキーボード７１５あるいはポインティングデバイス７
１７に対して応答する様式、を制御する。 ポインティングデバイスは、ディスプレイ７１３におけるポインタ７
１４を制御する。 Ｘｔｅｎｔは、これらのウィジェットを、グラフ７２７及び７２９及びユーザからの入力によって要求されるように操作する。 Ｘｔｅｎｔライブラリルーチン７１９はＸｔｅｎｔスペシフィケーションファイル７２１を用いる。 ＣＬＡＳＳＩＣオブジェクト、ｌ
ｉｂｇｒａｐｈ７０９によって生成されたデータストラクチャにおける対応するノード、及びディスプレイ７１
３における対応するオブジェクトは、ＣＬＡＳＳＩＣオブジェクトに固有の識別子によって全て識別される。 この種の識別子は、ＣＬＡＳＳＩＣオブジェクトが生成された時点で各々のオブジェクトに割り当てられる。

【００５６】Ｃコード７０３の２つの特別なコンポーネントで以下により詳細に記述されるのは、フィーチャーが顧客デリバリに対して追加された場合に矛盾点チェックを行なうコンシステンシーチェッカー７１０、及びユーザが属性マップ７０８をエディットすることを可能にするマッピングエディタ７１２である。

【００５７】実際の動作においては、インプリメンテーション７０１は、まず、固定ＣＬＡＳＳＩＣデータベース７０４中のコンポーネント及びストラクチャ情報からポテンシャルグラフ７２５を構成することによって、自らを初期化する。 その後、ユーザはマウス７１７を用いて、サーチエリア２１１に表示される固定データベース７０４の表示を選択する。 Ｘｔｅｎｔ７１９は、このことに応答して、ポテンシャルグラフ７２５から希望されている表示のサーチグラフ７２７を構成し、このサーチグラフ７２７をＸｔｅｎｔ７１９宛に提供する、Ｃコード７０３内のコールバックルーチンを規定する。 Ｘｔｅ
ｎｔ７１９は、情報及び属性マップ７０８を用いて、グラフ表示に対して必要とされているウィジェットを生成する。 ユーザが新たな検索を規定する度ごとに、固定Ｃ
ＬＡＳＳＩＣデータベース７０４において検索が実行され、その結果が、ポテンシャルグラフ７２５から新たなサーチグラフ７２７を生成してその新たなサーチグラフ７２７をＸｔｅｎｔ７１９宛に提供することによって表示される。 新たな検索が実行される度ごとに、直前の検索の結果が直前検索結果７２３にストアされる。

【００５８】ユーザがサーチエリア２１１に表示されたノードをワークエリア２１５に含めるべきものであるとして選択すると、システムはその選択に応答して対応するオブジェクトを固定ＣＬＡＳＳＩＣデータベース７０
４からワーキングＣＬＡＳＳＩＣデータベース７０６へ追加する。 オブジェクトを追加する際、必要となる依存関係管理チェックが，ＣＬＡＳＳＩＣ７０５内のルーチン及びＣコード７０３内のルーチンを用いて実行される。 必要とされる情報はデータベース７０４及び７０６
から入手される。 チェックの結果はデータベース７０６
に記録される。 その後、ワーキングデータベース７０６
内のオブジェクトからワーキンググラフ７２９が生成され、表示のためにＸｔｅｎｔ７１９に供給される。 ワーキンググラフ７２９は依存関係管理チェックの結果を含んでおり、それゆえワーキンググラフ７２９のワークエリア２１５内での表示は前記結果を表示することになる。

【００５９】ワークエリア２１５に表示されていたノードを削除すると、ワーキングデータベース７０６が修正され、依存関係管理チェックが実行される。 この削除と新たな依存関係管理チェックの結果の双方を反映した新たなワーキンググラフ７２９が生成され、表示のためにＸｔｅｎｔに提供される。 最後に、ユーザがワークエリア２１５に表示されているグラフを固定ＣＬＡＳＳＩＣ
データベース７０４にセーブすべきものであると規定した場合には、ワーキングデータベース７０６中のＣＬＡ
ＳＳＩＣオブジェクトが固定ＣＬＡＳＳＩＣデータベース７０４に追加される。 以下により詳細に説明されているように、本発明の望ましい実施例においては、依存関係管理のある部分を実行するためにＣコード７０３内のルーチンを利用する。 なぜなら、必要とされる機能がＣ
ＬＡＳＳＩＣでは利用可能ではないからである。

【００６０】ＣＬＡＳＳＩＣにおけるフィーチャードメインの表示： 図８ ＣＬＡＳＳＩＣデータベースにおいては、オブジェクトは概念（コンセプト）の階層構造に従って順序付けられている。 コンセプトに属する全てのオブジェクトは値を含むスロットを有している。 この値は文字列あるいは数字であるか、もしくは他のオブジェクトである。 図８
は、本発明の望ましい実施例において用いられているＣ
ＬＡＳＳＩＣコンセプト階層構造を示している。 図８においては、コンセプトは四角形の箱によって表わされている。 コンセプトの名前は、箱の中にローマン（Ｒｏｍ
ａｎ）フォントで示されている。 太線の矢印は、コンセプト間のコンセプト−サブコンセプト関係を示している。 コンセプトのスロットは、箱の中のイタリックフォント（斜体字）によって示されている。 スロットが値として他のオブジェクトを必要とする場合には、そのスロットが属するコンセプトからそのスロットを埋めるべきオブジェクトに係るコンセプトへ細線の矢印が描かれている。 ここのオブジェクトはローマンフォントで示されており、矢印によってそれぞれのコンセプトに結び付けられている。

【００６１】階層構造における最も広範なコンセプトはＲＤＤＩＴｈｉｎｇ８０３であり、顧客デリバリを生成するために用いられるあらゆるオブジェクトが属している。 ＲＤＤＩＴｈｉｎｇ８０３の中間サブコンセプトには、フィーチャークラスタオブジェクトが属するコンセプトであるフィーチャークラスタ８０５、フィーチャーオブジェクトが属するコンセプトであるフィーチャー８
０７、フィーチャーにおけるオプションであるオブジェクトが属するコンセプトであるオプション８０９、現在開発されつつあるオブジェクトが属するコンセプトであるワークアイテム８１１、デリバリオブジェクトが属するデリバリ８１９、及び、スイッチアプリケーションであるオブジェクトが属するコンセプトであるアプリケーション８１１が含まれる。 フィーチャーコンセプト８０
７は、バウンドオプションを有するフィーチャーオブジェクトが属しているサブコンセプトであるバウンドフィーチャーサブコンセプト８１５を有しており、バウンドフィーチャーサブコンセプト８１５は、デリバリの一部であるフィーチャーオブジェクトが属するサブコンセプトであるフィーチャー・イン・デリバリサブコンセプトを有している。 図８は、アプリケーションコンセプト８
３１の実例である、わずかのオブジェクト８２１のみを示している。

【００６２】フィーチャーコンセプト８０７は、ＣＬＡ
ＳＳＩＣデータベース中でスロットがオブジェクトを互いに関連付けている方式の一例として考えることができる。 与えられたフィーチャーに係るフィーチャーオブジェクト中の”必要”スロットは、その与えられたフィーチャーに関して必要とされるフィーチャーを表わす他のフィーチャーオブジェクトのリストを含んでいる。 ”矛盾”スロットは、与えられたフィーチャーと矛盾するフィーチャーを表わす他のフィーチャーオブジェクトのリストを含んでいる。 ”オプション”スロットは、与えられたフィーチャーのオプションを規定するオプションコンセプトに属するオブジェクトのリストを含んでいる。
残りのスロットは、そのスロットの名前によって示された情報に係るテキスト文字列を含んでいる。

【００６３】階層構造８０１に従って順序付けられたオブジェクトが、検索、サーチエリア２１１及びワークエリア２１６における表示、無撞着性の維持、及び固定データベース２０２の更新に関して必要とされる情報を含んでいることは明らかである。 例えば、フィーチャーオブジェクトにおける”作者”及び”記述”スロットは、
それらオブジェクトの作者、名前、あるいはＩＳＤＮ等のキーワードによる検索を可能にしている。 ”必要”スロットは、与えられたフィーチャーが必要とする全てのオブジェクトをサーチエリア２１１内のグラフあるいはワークエリア２１５内のグラフに対して追加すること、
及び与えられたフィーチャーが削除された場合にどのフィーチャーがサポートされなくなるかを決定すること、
を可能にする。 ”矛盾”スロットは、あるフィーチャーがワークエリア２１５に追加された場合にワークエリア内の他のあらゆるフィーチャーと矛盾を起こすか否かを決定することを可能にする。 アプリケーションあるいはフィーチャークラスタオブジェクトが固定データベース２０２に追加される場合には、そのアプリケーションあるいはフィーチャークラスタオブジェクトに係るスロットにおいて規定された新たなフィーチャーオブジェクトの全ても固定データベース２０２に追加され、新たなフィーチャーオブジェクトが追加される場合には、そのフィーチャーオブジェクトのデフォールトオプション設定であるバウンドフィーチャーオブジェクトも追加される。

【００６４】無撞着性チェック： 図６ 既に指摘されているように、システム２２３のプロセス３は、ワークエリア２１５に対してノードが追加されたり削除されたりした場合に必ず無撞着性チェックを実行する目的でルール２０７を用いる。 本発明の望ましい実施例においてはＣコード７０３中のコンシステンシーチェッカー７１０によって実行されるこれらのチェックが図６の表６０１にまとめられている。 以下、これらのチェックがどのようにして適用されているかを例示する目的で単純な例が記述される。 まず、フィーチャーデータベースが、フィーチャーＡ、Ｂ、Ｃ、Ｄ、Ｘ、Ｙと、Ａ
がＢを必要とし、ＡがＣを必要とし、ＢがＤを必要とし、ＸがＣを必要とし、そしてＹがＤと矛盾する、という関係とを含んでいると仮定する。 以下、このデータベースを利用する簡単なシナリオをトレースして考える。
ここでは、小文字はデフォールトバウンドフィーチャーであるとする。 すなわち、ａはＡのデフォールトバウンドフィーチャーである。 ”ユーザがフィーチャー．．．
を追加する”は、”ユーザが、フィーチャー． ． ． がデリバリに対して追加されることを要求する”として理解されるべきものである。

【００６５】１． ユーザがフィーチャーＡを追加する システムは、ａをデリバリに対して追加するためにクラス→デフォールトメンバー推論を適用する。 ＡがＢ及びＣを必要とするため、システムはＢ及びＣに関するバウンドフィーチャーが既にデリバリ中に存在しているか否かを確認するためのチェックを行なう。 それらは存在していないため、システムはｂ及びｃを追加し、ａからｂ
へ、及びａからｃへ”必要”リンクを生成し、ｂからａ
へ、及びｃからａへ”正当化”リンクを生成する。 同様に、ＢがＤを必要とするため、システムはｄをデリバリに追加し、ｂからｄへの”必要”リンク及びｄからｂへの”正当化”リンクを生成する。 システムがグラフを表示する場合には、ｂ、ｃ、及びｄに対しては、それらがシステムによって追加されたものであることを表わすためにイタリックフォントが用いられる。

【００６６】２． ユーザがフィーチャーＸを追加する システムはＸをデリバリに追加する。 ＸがＣを必要とするため、システムはｃがデリバリ中に存在するか否かを確認するためのチェックを行なう。 ｃは存在しているため、システムは、ｘからｃへの”必要”リンク及びｃからｘへの”正当化”リンクを追加するのみである。

【００６７】３． ユーザがフィーチャーＹを追加する システムはＹをデリバリに追加する。 ＹがＤとは矛盾するため、システムはｄがデリバリ中に存在するか否かを確認するためのチェックを行なう。 ｄがデリバリ中に存在しているため、ｙとｄとの間に”矛盾”リンクが生成される。 この時点で、ワーキングＣＬＡＳＳＩＣデータベース７０６中のデリバリの内部表現はいかのようになる（記述を明瞭にするために簡略化されている）： ａ−ｂ、ｃが必要 正当化： ユーザによる ｂ−ｄが必要 正当化： ａ ｃ−正当化： ａ、ｘ ｄ−正当化： ｂ 矛盾： ｙ ｘ−ｃが必要 正当化： ユーザによる ｙ−正当化： ユーザによる 矛盾： ｄ ワークエリア２１５内のグラフは、もちろんワーキングＣＬＡＳＳＩＣデータベース７０６の表現に対応している。

【００６８】４． ユーザがｄの削除を試みる システムはこれを許可しない。 なぜなら、ｄはｂによって必要とされているからである。

【００６９】５． ユーザがｙを削除する システムはこの削除を許可し、ｙが削除されたものとしてマークする。 （削除はアンドゥ可能である。それゆえ、削除されたオブジェクトは内部データストラクチャには、適切なマーキングがなされた上で残存している。）このことにより、ｄのステータスが更新され、無撞着である旨が示される。 最後に、新たなステータスを表示するために、ｙ及びｄの表示の更新がなされる。

【００７０】６． ユーザがａを削除する システムはａを削除されたものとしてマークする。 このことにより、ｂが”未サポート”としてマークされることになる。 なぜなら、ａのみがｂの”正当化”を有していたからである。 次いで、ｄが未サポートになる。 なぜなら、ｂのみがｄの”正当化”を有していたからである。 但し、ｃはｘによって正当化されているため、そのステータスは変わらないことに留意されたい。 その後、
システムは、ａ、ｂ、及びｄの表示を更新する。

【００７１】この例においては、理由付け機能のうちの重要な部分が、ＣＬＡＳＳＩＣではなくＣプログラミング言語を用いてインプリメントされている。 ＣＬＡＳＳ
ＩＣは、理由付けの扱いやすさを保証するために、表現機能を制限するように慎重に設計されたものである。 しかしながら、ＣＬＡＳＳＩＣが満足しない複数個の要求を満たすことが必要である。 第一に、デフォールト機能が必要とされている。 フィーチャーはＣＬＡＳＳＩＣコンセプト（クラス）として表現されているが、ユーザはフィーチャーがデリバリに対して追加されることを要求する場合には、真に追加されなければならないものはバウンドフィーチャーである（一つの例）。 第二に、存在の定量化とバインド変数との利用を可能にするルールが必要とされている。 これら双方の機能は、フィーチャーＦ１がデリバリに対して追加された場合に必ずなされる依存関係処理を記述するルールを定義するために必要である（Ｆ１及びＦ２はフィーチャー、ｆ１及びｆ２はそれぞれＦ１及びＦ２に対応するバウンドフィーチャーである）。 Ｆ１が必要とする全てのＦ２に関して、Ｆ２に属するあるｆ２がデリバリ中に存在する場合には、 ｆ１からｆ２への正当化を追加する それ以外の場合には、 Ｆ２のデフォールトバウンドフィーチャーをデリバリに追加してそれをｆ２とする ｆ１からｆ２への正当化を追加する

【００７２】前述されているように、ディスプレイ７１
３に表示されているグラフ中のノード及びリンクは、Ｘ
ウィンドウウィジェットである。 よって、ノード及びリンクが表示される様式は、ウィジェット中のリソースをセットすることによって制御される。 本発明の望ましい実施例においては、ノードに関連するリソースは以下のようなものである： ・前景及び背景色及びパターン ・ノードの形 ・ラベル用のフォント ・線幅 リンクに関連するリソースは以下のようなものである： ・リンクの色 ・リンクの幅 ・ラインタイプ：実線、破線、等など。

【００７３】ノードあるいはリンクに対するウィジェットが生成される場合には、そのウィジェットに関するリソースの各々に対して、リソースが有する値の種類を規定するタイプが与えられる。 生成時、あるいは後に、リソースにはそのタイプの値がセットされる。

【００７４】マッピングエディタ７１２は、まず、ノードによって表現されるアーティファクトの属性を前述のリソースに対して割り当て、その後に、属性に対して割り当てられたリソースが有する値の種類とこれらディスプレイリソースの各々において用いられる値の組とを決定することをユーザによるインプリメンテーション７０
１に対して可能にする。 ユーザは、属性が割り当てられていない場合には、ディスプレイリソースに対してデフォールト値を規定することもできる。

【００７５】本発明の望ましい実施例においては、ユーザは、フィーチャーに係る以下の属性がそのフィーチャーを表現しているノードの表示においてどのように現れるかを決定する目的で、マッピングエディタを利用することが可能である： ・オリジネーション マッピングされたリソースは、そのノードによって表現されるフィーチャーがアプリケーションの一部であるか、システムによって追加されたものであるか、あるいはユーザによって追加されたものであるかを表わす。 ・ステータス マッピングされたリソースは、そのノードによって表現されるフィーチャーが正常であるか、削除されたか、矛盾を生じているか、あるいは未サポートかを表わす。 ・マルチプルバウンドフィーチャー マッピングされたリソースは、そのノードによって表現されるフィーチャーがその選択肢としてマルチプルバウンドフィーチャーを有しているか否かを表わす。 ・選択済み マッピングされたリソースは、そのノードによって表現されるフィーチャーがワークエリア２１５への追加のためあるいはワークエリア２１５からの削除のために選択されているか否かを表す。

【００７６】リンクの表現を決定する属性は以下のようなものである： ・リンクタイプ リンクされたノードによって表現されるフィーチャー間の関係、すなわち、あるフィーチャーが別のフィーチャーを必要としている、フィーチャーがコンパチブルではない、ノードがパッケージ中の基本フィーチャーである、あるいはそれがプレミアムフィーチャーである、等を表わす。 ・リンクステータス そのリンクが正常であるかあるいは削除されているかを表す。

【００７７】マッピングエディタを用いることによって、ユーザは、例えば、ノードのオリジンが背景色によって表示されるべきものであるということを決定することが可能であり、次いで、どの背景色がどのリソースを表現するかを決定することが可能である。 残りのリソースは、デフォールト値を保持しているか、そのリソースに対して過去において割り当てられた属性によって決定された値を有しているかのいずれかである。

【００７８】図９は、システム７０１のユーザによって、フィーチャーの属性をリソースに対してマッピングするために用いられるウィンドウ９０１を示している。
ウィンドウ９０１は、３つの基本的な部分よりなる：セクション９０５、９０７、９０９は、リソースを属性に対してマッピングし、属性の値をリソースの値に対してマッピングする。 セクション９０３は、ユーザが、マッピングされていないリソースに対するデフォールト値を決定することを可能にする。 セクション９１１は、ユーザが、特定のマッピングの組を有するノードあるいはリンクがどのように見えるかを試すことを可能にする。

【００７９】セクション９０５においては、ユーザは、
まずノードあるいはリンクリソースがマッピングされているか否かを選択し、次いでどのリソースがマッピングされつつあるのかを選択する。 ここ及びウィンドウ９０
１全体を通じて用いられる慣用であるが、選択肢は、必要な場合にはスクロールすることが可能な水平リストとして表現される。 選択肢は、マウスを用いてリストから選択される。 例えば、第一のリストが、ユーザがマッピングされるノードあるいはリンクリソースを選択することを可能にすると、ユーザはノードを選択すると、その後、第二のリストはマッピング可能なノードリソースを表示し、ユーザがそのうちの幾つかを選択する。 ここでは、ノードフォント、ノード前景／フォント色、及びノード背景色が選択されている（ノード背景色は、リストからスクロールされてしまっている）。

【００８０】その後、選択されたリソースはセクション９０７に現れる。 セクション９０７は、属性の選択されたリソースへのマッピングを規定する。 セクション９０
７は左側に（スクロール可能な）属性のリストを有しており、各々の属性に関して、セクション９０５において選択されたリソースのリストを有している。 属性をリソースに対してマッピングするために、ユーザはマウスを用いてポインタをその属性に係るリソースリストに移動し、希望するリソースを選択する。 もちろん、与えられたリソースには単一の属性しかマッピングできない。 ここでは、ノードフォントリソースがオリジナル属性にマッピングされ、ノード背景色リソースがステータス属性にマッピングされている。

【００８１】属性がリソースに対してマッピングされると、属性の値をマッピングされたリソースに対してマッピングするためにセクション９０９が用いられる。 ここでは、この作業はステータス属性に対してなされている。 ステータス属性は４つの値を有している。 この場合には、これらの値が左側にリストされ、各々の値が取り得る色のリストを右側に有している。 値に対する色を選択するために、ユーザはリストから色を選択する。

【００８２】セクション９０３は、リソースに対するデフォールト値を選択するために既に記述されている技法を用いる。 左側のリストは利用可能なリソースを表し、
各々のリソースの右側のリストはそのリソースに対する取り得る値を示している。 セクション９１１は、ユーザが、エリア９０５、９０７、９０９、及び９０３におけるユーザ自身の選択の結果をプレビューすることを可能にしている。 セクション９１１のセクション９１３は、
ユーザが、ノードによって表わされているフィーチャーの属性の値を規定することを可能にすると、セクション９１１は、ユーザが、リンクに関する属性の値を規定することを可能にすると、他のセクションに係る技法が選択に関して利用される。 属性選択の結果は、エリア９１
７に表示される。

【００８３】ユーザは、選択及びその結果のチェックを終了すると、マウスを用いてボタン９１９を起動する。
このボタン９１９は、属性マップ７０８を選択によって要求されるように変更する。 上記説明から明らかなように、属性マップ７０８は、各々のマッピング可能な属性に係るエントリを有する表として実現されている。 マッピング可能な属性に係るエントリは、その属性に対応するウィジェットリソース、その属性の取り得る値、及び各々の属性値に対応するリソース値を示している。 個別の表がデフォールトリソース値を規定する。 Ｘｔｅｎｔ
７１９がｌｉｂｇｒａｐｈ７０９によって管理されているグラフのうちの一つのノードからウィジェットを作成する場合には、Ｘｔｅｎｔ７１９は、マッピングされる属性に対するリソースを設定するために属性マップ７０
８中の表を用いる。 残りのリソースは、デフォールトリソース値に係る表に規定されているように規定される。

【００８４】以上の説明は、本発明の一実施例に関するもので，この技術分野の当業者であれば、本発明の種々の変形例が考え得るが、それらはいずれも本発明の技術的範囲に包含される。 上記記述は、アーティファクトからプロダクトを構成するシステムを作成してそれを利用するための、現時点で最良の方式に係るものである。 本発明に係るシステムにおける重要な側面には以下のものが含まれる： ・プロダクトに係る固定データベース中のあらゆるストラクチャあるいはプロダクトを本質的に含むパレットの提供 ・前記パレットの結果の種々の側面及びプレゼンテーションに従ったデータベースの検索機能 ・ストラクチャを表現するための、パレット及びワークエリアにおけるグラフの利用 ・アーティファクトに係る情報の、それらのアーティファクトを表現するグラフへの統合 ・アーティファクトに係る情報とグラフ中でのその情報の表示との間のマッピングをエディットする機能 ・アーティファクトがパレットからワークエリアに移動させられた場合及びアーティファクトがワークエリアから削除された場合のコンシステンシーチェック ・ワークエリアの内容の固定データベースへの追加機能

【００８５】上記記述には、本発明に係るシステムをインプリメントするための最良と思われる方式が含まれているが、ここに記載されている性質のうちの幾つかを有するシステムをインプリメントする方法は複数個存在する、ということは当業者には明らかである。 例えば、システムは、Ｃ言語以外のプログラミング言語を利用し、
かつＵＮＩＸ以外のオペレーティングシステムを用いてインプリメントすることが可能であり、メインフレームやパーソナルコンピュータあるいはワークステーションにインプリメントすることが可能である。 ＣＬＡＳＳＩ
Ｃ以外のデータベースが固定データベース２０２及びワーキングデータベース２２１をインプリメントするために用いられることが可能であり、実際、標準的なデータベース及びコンシステンシーチェックのためのルールの個別の蓄積が、データベースの代わりに本発明に係るシステムのインプリメントにおいて用いられ得る。 同様に、ｌｉｂｇｒａｐｈ以外のグラフパッケージも用いられうるものであり、同様にＸウィンドウ以外のグラフィカルユーザインターフェースシステム及びＸｔｅｎｔ以外のＸウィンドウインターフェースも用いられ得る。 加えて、マッピングエディタが、ウィジェットリソースに対して種々の属性値をマッピングするために用いられ得る。 さらに、本発明の目的は、本明細書に記載されているものとは相異なったグラフィカルディスプレイ及びユーザインターフェースを用いることによっても実現され得る。

【００】

【発明の効果】以上述べたごとく、本発明によれば、従来技術に係る問題点を解決した、既存のコンポーネントからカスタムシステムを構成するタスクを支援する装置が提供される。

【図面の簡単な説明】

【図１】本発明に係るアーティファクト構成のモデルを示したブロック図。

【図２】本発明の望ましい実施例を示すブロック図。

【図３】本発明の望ましい実施例におけるメインディスプレイを示す図。

【図４】本発明の望ましい実施例において用いられる検索メニューの詳細を示す図。

【図５】本発明の望ましい実施例における機能オプション割り当てを規定するために用いられるメニューを示す図。

【図６】本発明の望ましい実施例において依存関係及び矛盾点を検出する目的で用いられる推論を示す表。

【図７】本発明の望ましい実施例の詳細を示すブロック図。

【図８】本発明の望ましい実施例において用いられるＣ
ＬＡＳＳＩＣ知識ベースの構造の概要を示す図。

【図９】本発明の望ましい実施例におけるマッピングエディタに用いられる表示を示した図。 各々の図面に示されている参照番号のうち、下２桁はアイテムの図面内での番号を表わし、最上位の数字はそのアイテムが最初に出現した図面番号を示している。 よって、参照番号２０
１を有するアイテムは、最初に図２に現れる。

【符号の説明】

１０１ アーティファクト構成モデル １０３ パレット １１３ ワークエリア １３１ プロダクトデータベース １３３ アーティファクト情報 １３５ 依存関係 ２０１ アーティファクト構成システム ２０２ 固定データベース ２０３ コンポーネント ２０５ ストラクチャ ２０７ ルール ２０９ プロセス２ ２１１ サーチエリア ２１２ ボタン ２１３ グラフ ２１５ ワークエリア ２１７ グラフ ２２１ ワーキングデータベース ２２３ プロセス３ ２２５ ストラクチャのＤＢへの追加 ７０１ インプリメンテーション ７０３ Ｃコード ７０４ 固定ＣＬＡＳＳＩＣデータベース ７０５ ＣＬＡＳＳＩＣ ７０６ ワーキングＣＬＡＳＳＩＣデータベース ７０７ ＣＬＡＳＳＩＣデータファイル ７０８ 属性マップ ７０９ ｌｉｂｇｒａｐｈ ７１０ 無撞着性チェック ７１２ マッピングエディタ ７１３ ディスプレイ ７１５ キーボード ７１７ ポインティングデバイス ７１９ Ｘｔｅｎｔ ７２１ Ｘｔｅｎｔスペシフィケーションファイル ７２３ 過去の検索結果 ７２５ ポテンシャルグラフ ７２７ サーチグラフ ７２９ ワーキンググラフ ８０１ 階層構造 ８０３ ＲＤＤＩＴｈｉｎｇ ８０５ フィーチャークラスタ ８０７ フィーチャー ８０９ オプション ８１１ ワークアイテム ８１３ アプリケーション ８１５ バウンドフィーチャー ８１７ デリバリ内フィーチャー ８１９ デリバリ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ローレン ギルバート ターヴィーン アメリカ合衆国，07920 ニュージャージ ー，バスキング リッヂ，ローカスト レ イン 175