JPH08110892A - システム構成装置 - Google Patents

Abstract

(57)【要約】 【課題】 アーティファクト（ａｆ）に関する情報の可
視化、フレキシブリティ、容易な検索可能性、即時的な
ビジュアルフィードバック可能性を提供する。 【解決手段】 本発明のプリミティブアーティファクト
（ｐａｆ）及び複合アーティファクト（ｃａｆ）から新
たなｃａｆを構成するための装置は、ｐａｆ、予め構成
されたｃａｆ、ｐａｆからｃａｆが構成される様式を規
定するルールに係る固定データベース（ｄｂ）を有して
いる。この固定ｄｂからのａｆは、サーチエリア内に指
示グラフとして表示され、このグラフのａｆがノードに
よって表現される。ユーザは固定ｄｂを検索することが
可能であり、サーチエリアの指示グラフは検索の結果を
表示する。新たなｃａｆを構成するｃａｆに追加するた
めに、ユーザは、希望するコンポーネントａｆを表現す
る、指示グラフ中のノードを選択する。希望されたａｆ
に係る情報は、固定ｄｂから稼働ｄｂへコピーされ、稼
働ｄｂの内容に係る指示グラフがワークエリアに表示さ
れる。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

【従来の技術】共同作業に対する自動化された支援に関
する一般的な説明に関しては、L.G.Terveen, "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, S.M., Tolon, W.
J., Bogia, D.P., and Bignoli, C., "Flexible, Activ
e Support for Collaborative Work with Conversation
Builder", In Proc. of CSCW'92, ACM, N.Y., 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, N.Y., 1992, pp.281-288 に記載
されている。

【０００３】アーティファクトベース（Artifact-base
d）のアプローチは、グループワークの一部として生成
されて操作されるアーティファクト、すなわちワークプ
ロダクト、及びその生成及び使用を支配する規則に係る
コラボレーションをオーガナイズする。この種のアプロ
ーチに関しては、Fischer, G., Grudin, J., Lemke, A.
C., McCall, R., Ostwald, J., Reeves, B.N., 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, N.Y., 1
992, pp.394-401;あるいは Wroblewski, D.A., Hill,
W.C., 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, T.W., Lai, K.Y., and Fry, C., "E
xperiments with Oval: A Radically Tailorable Tool
for Collaborative Work", In Proc. of CSCW'92, ACM,
N.Y., 1992, pp.289-297, に記載されている。オーバ
ルは、４つのコラボレーティブシステム、すなわちザ・
コーディネータ及び３つのアーティファクトベースのシ
ステムであるｇＩＢＩＳ、ロータスノーツ（Lotus Note
s）、及びインフォメーションレンズ（Information Len
s）、をインプリメントするために用いられてきてい
る。このようなフレキシビリティを可能にするオーバル
の２つのキーとなる側面は、セミストラクチャードオブ
ジェクトの表現設定及びルールメカニズムである。オー
バルは、アクティビティを含む関連するあらゆるものを
表現するためにオブジェクトの生成を可能にし、ルール
はオブジェクトがどのように処理されるべきかを規定す
るように表現され得る。ツールキットベースの別の例
は、Kaplan, S.M., Tolon, W.J., Bogia, D.P., and Bi
gnoli, C., "Flexible, Active Support for Collabora
tive Work with ConversationBuilder", In Proc. of C
SCW'92, ACM, N.Y., 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, R.J., McGuinness, D.L., Patel-Schneider, P.F.,
Resnick, L.A., 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, S.C., and Vo, K.P., "Dictionary a
nd Graph Libraries", in Winter USENIX Conference P
roceedings, 1993, pp.1-11を参照されたい。図７は、
コンポーネント間の関係を示している。インプリメンテ
ーション７０１は、処理コンポーネント２０９、２２
３、２２５をインプリメントしているＣコード７０３を
含んでいる。このコードは、ＣＬＡＳＳＩＣ７０５、ｌ
ｉｂｇｒａｐｈ７０９、及びＸｔｅｎｔ７１９からのラ
イブラリルーチンの起動を含んでいる。フィーチャーに
関する実際のデータは、ＣＬＡＳＳＩＣデータファイル
７０７において維持されている。インプリメンテーショ
ン２０１が実行されている場合には、ＣＬＡＳＳＩＣ
は、２つのデータベース、すなわち固定データベース２
０２をインプリメントする固定ＣＬＡＳＳＩＣデータベ
ース７０４とワーキングデータベース２２１をインプリ
メントするワーキングＣＬＡＳＳＩＣデータベース７０
６、をメモリ内に実現するために、ＣＬＡＳＳＩＣデー
タファイル７０７内の情報を利用する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００】

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

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

【符号の説明】

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

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

Claims (4)

【特許請求の範囲】
1. 【請求項１】 ユーザに対してノード及び／あるいはエ
   ッジに係る属性を有するグラフの表示方法を規定するこ
   とを許可する、コンピュータシステムでインプリメント
   された装置において、 前記コンピュータシステムにおいてストアされていて前
   記グラフの前記ノード及びエッジを表現するグラフデー
   タストラクチャと、 前記コンピュータシステムにおいてストアされていて前
   記グラフの表示に係る性質（プロパティ）にある種の属
   性を関連付ける属性マッピングデータストラクチャと、 前記コンピュータシステムにおいて実行され、前記ユー
   ザからの入力に応答して前記属性マッピングデータスト
   ラクチャを修正するマッピングエディタと、 前記コンピュータシステムにおいて実行され、前記グラ
   フデータストラクチャ及び前記属性マッピングデータス
   トラクチャに応答して、前記コンピュータシステムにお
   けるディスプレイ手段に前記グラフデータストラクチャ
   と前記属性マッピングデータストラクチャによって規定
   されるディスプレイプロパティとによって規定されるノ
   ード及びエッジを有するグラフを表示するグラフジェネ
   レータと、を有することを特徴とするシステム構成装
   置。
2. 【請求項２】 コンピュータシステムにおいてインプリ
   メントされた、インタラクティブにターゲットシステム
   を規定する装置において、 前記コンピュータシステムにおいてグラフの表現からデ
   ィスプレイ手段中に前記グラフの表示を生成する手段
   と、 前記ターゲットシステムがそこから構成されるプリミテ
   ィブの組み合わせを規定する第一のグラフの表現を少な
   くとも含む、前記コンピュータシステムからアクセス可
   能な第一データベースと、 前記ターゲットシステムの少なくとも一部を規定する第
   二のグラフの表現を含む、前記コンピュータシステムか
   らアクセス可能な第二データベースと、 前記第一のグラフの前記表現から前記表示生成手段によ
   って生成された前記第一のグラフを表示する、前記ディ
   スプレイ手段中の第一エリアと、 前記第二のグラフの表現から前記表現から前記表示生成
   手段によって生成された前記第二のグラフを表示する、
   前記ディスプレイ手段中の第二エリアと、 前記第一エリア中の前記第一のグラフの一部を前記第二
   データベース中に追加されるものとして選択するインタ
   ラクティブコンポーネント選択手段と、 前記インタラクティブコンポーネント選択手段に応答し
   て前記第一のグラフの前記選択された部分に対応する前
   記第一のグラフの前記表現の前記部分に対応する部分を
   前記第二のグラフの前記表現に追加する手段と、を有す
   ることを特徴とするシステム構成装置。
3. 【請求項３】 前記第二のグラフによって表現された前
   記組み合わせが前記第一データベースへ追加されるべき
   ものであることを示すインタラクティブ組み合わせ追加
   手段と、 前記インタラクティブ組み合わせ追加手段に応答して前
   記第二のグラフに対応する表現を前記第一データベース
   へ追加する手段と、を更に有することを特徴とする請求
   項第２項に記載のシステム構成装置。
4. 【請求項４】 少なくとも前記プリミティブの無撞着な
   組み合わせを規定する、前記コンピュータシステムから
   アクセス可能なルールの組を有しており、 前記表示生成手段が、前記ルールの組に応答して前記第
   二のグラフが一つあるいは複数個の前記ルールと矛盾す
   るか否かを前記第二のグラフの前記表示中に示すことを
   特徴とする請求項第２項に記載のシステム構成装置。