ドキュメント抽象
wt.doc パッケージは、管理されたドキュメントの標準の実装を提供します。簡略化したドキュメントモデルを以下に示します。この簡略化した図では、WTDocument および WTDocumentMaster を構成するいくつかの主要インタフェースを示します。これらのオブジェクトは、動作を捕捉するための複数のインタフェースを実装しています。これら 2 つのオブジェクトが実装されているインタフェースの全容については、wt.doc.WTDocument および wt.doc.WTDocumentMaster の Javadoc を参照してください。
Doc パッケージ
ドキュメントクラスは、wt.enterprise パッケージ内の制御リビジョンオブジェクトのために確立されたパターンに基づいて実装されます。WTDocumentMaster と WTDocument クラスは、wt.enterprise 内で確立された管理特性を示す具象クラスを提供し、ドキュメントに特性を加えます。ドキュメントのプロパティは、WTDocument クラスで指定されます。その後、正常化のためにプロパティのすべてが WTDocumentMaster に保存されます。厳密には、WTDocument が Format ContentHolder を実装して、プライマリコンテンツアイテムと複数のセカンダリコンテンツアイテムを与えます。WTDocument は、ほかのドキュメントとの 2 種類の関連を作成できます。最初の WTDocumentUsageLink は、WTPartUsageLink に類似し、IteratedUsageLink をサブクラス化します。これは量を持ちません。WTDocumentUsageLink は、ドキュメントとドキュメント構造間の親子関係を作成するために使用されます。ドキュメントがサブドキュメントで作成され、このサブドキュメントがほかのドキュメントによって再使用できる場合や個別に制御される必要のある場合に、ドキュメントはこのリンクを使用します。部品の実装と同じように、WTDocumentService には、この関係をナビゲーションする便利なメソッドがあり、結果をフィルタするために WTDocument ConfigSpec があります。次に、WTDocumentDependencyLink は IteratedDescribeLink を実装します。IteratedDescribeLink は WTPartDescribeLink によっても実装されています。この関係は、2 つのドキュメント間のバージョン固有のものです。この関係は、参照としてクライアントに表示されます。2 つのドキュメント間の参照は、ほかのドキュメントへの依存を示すために作成できます。ドキュメントは、別のドキュメントのいくつかの情報を参照するため、作成または交信中にこのドキュメントへの参照が追加されます。関連参照には、参照の存在理由や依存を説明するために使用されるコメント属性があります。WTDocument サービスには、WTDocumentDependencyLink をナビゲーションするための便利なメソッドがあります。
ドキュメントパッケージは、制御リビジョンビジネスサブクラスを実装する例です。具象ドキュメントビジネスクラスは、エンタープライズモデルの制御リビジョンビジネスモデル (マスターと RevisionControlled) テンプレートから継承されます。ドキュメントは、機能のほとんどを RevisionControlled エンタープライズオブジェクトから継承します。RevisionControlled はプラグアンドプレイ機能インタフェースを併合します。インタフェースの完全なリストについては、Javadoc の wt.enterprise.Revisioncontrolled を参照してください。特に、wt.enterprise.Revisioncontrolled には、コンテンツパッケージからのインタフェースも含まれます。これは、WTDocument がコンテンツホルダーであることを意味しています。つまり、ファイルまたは URL が WTDocument に含まれます。
属性は、WTDocumentMaster または WTDocument にあります。WTDocumentMaster の属性は、すべてのバージョンと作業版数に対して同じ値を持ちます。マスターの属性が、いくつかのバージョンと作業版数が作成された後で変更されると、変更はすべてのバージョンと作業版数に反映されます。WTDocument の属性は、通常、各作業版数に対して異なる値を持つことができるため、変更は 1 つの作業版数にだけ影響します。このため、コンテンツホルダーは DocumentIteration で実装されます。
Windchill Foundation & PDM に一意の属性
ドキュメントの docType 属性は、すべての作業版数とバージョンに対して共通です。これは WTDocument に保存され、ドキュメントのタイプ属性に基づいてデータベースが分割されるようにするだけです。顧客が新しいドキュメントタイプを作成する場合は、DocumentType リソースバンドルに値を追加します。
DocumentType リソースバンドルはドキュメントのすべてのタイプを定義します。ユーザーがドキュメントを構築する場合は、列挙リストからドキュメントタイプを選択します。顧客は、リソースバンドルに値を追加して新しいドキュメントタイプをリストに追加できます。ドキュメントタイプの "$$" というプリフィックスは、Windchill に提供されたドキュメントタイプであることを示しています。顧客のドキュメントタイプに "$$" というプリフィックスは使用しないでください。
DocumentType リソースバンドルを使用すると、ユーザーが選択できるドキュメントの新しいタイプを構築することができます。これには、管理面で以下の影響があります。
• 管理規則は、新しいドキュメントタイプを認識しません。このため、管理面ではすべてのドキュメントタイプが同一です。これらには同じアクセス制御とインデックシング規則が適用されます。
• ワークフローの面では、docType プロパティはワークフロー分岐ロジックのアクティビティ変数として使用できます。
別の管理制御を持つ新しいドキュメントタイプを追加するには、WTDocument クラスを拡張する必要があります。いくつかのドキュメントだけが参加できる特定の関連がある場合は、WTDocument のサブクラス化も有効です。WTDocument をサブクラス化せずにこれらのルールを指定するのは困難です。WTDocument を拡張する場合は、以下の規則を使用します。
• WTDocument のすべての新しい子クラスに対して、DocumentType リソースバンドルで対応するエントリを作成する必要があります。この処理により、WTDocument の各子クラスの WTDocumentMaster オブジェクトがドキュメントバージョンのタイプを確実に知ることができます。
• ドキュメントの新しいクラスを追加する場合は、WTDocument クラスを拡張するだけで WTDocumentMaster クラスを拡張する必要はありません。WTDocument の子クラスはすべて、同じ WTDocumentMaster クラスを共有できます。
• WTDocument で確立されたコンストラクタパターンに従います。super.initialize() を起動した後、クラス特有のロジックを実行して、WTDocument の適切な初期化メソッドをオーバーライドします。特に、タイプが DocumentTypeRB.java に追加された値の代用となる場所を初期化するメソッド (番号、名前、タイプ) を起動します。
所属は、列挙タイプ属性または有効な値のリストとして実装されます。有効な値は、wt.doc.DepartmentListRB.java ファイルで定義されます。DepartmentListRB.java の値は、コードベース内での変更、ファイルのコンパイル、および置き換えが可能です。詳細については、列挙タイプを参照してください。