複数のカスタマで使用するカスタマイズを設計する場合、追加のガイドラインがあります。これらのガイドラインに従うことにより、より多くのカスタマでカスタマイズを使用できるようになるほか、各カスタマが複数のソースのカスタマイズを容易に使用できるようになります。

Creo Elements/Direct Model Manager のアーキテクチャでは、3 つのレイヤでカスタマイズをサポートしています。最下層のレイヤは、Creo Elements/Direct Manager Server オブジェクトです。中間のレイヤは CAD アプリケーション レイヤであり、Model (モデル)、Part (パーツ)、Drawing (図面) などの CAD データ管理オブジェクトを提供します。Design Management および Desktop の実装のオブジェクトは、最上位のレイヤにあります。

Design Management および Desktop のオブジェクトは、それぞれのアプリケーションのスキーマ (DM および DT) と強固に連結されています。Creo Elements/Direct Model Manager の新規カスタマ用のデフォルトスキーマは、DM です。既存のカスタマの多くが現在も DT スキーマを使用しており、その他のカスタマは独自のカスタム スキーマを使用しています。

CAD アプリケーションレイヤで作成されたカスタマイズは大部分の Creo Elements/Direct Model Manager カスタマで動作するとともに、同じレイヤにあるオブジェクトの CAD 機能を引き続き利用できるメリットがあります。ただし、DT または DM レイヤで行われていた動作については、引き続き把握する必要があります。たとえば、DM スキーマと DT スキーマはデータ属性を異なる方法で処理するため、どちらのスキーマが使用されているかをコードで判別してからデータ属性を初期化する必要があります。DT および DM オブジェクトのソース コードを参照し、対応する必要のある動作を確認してください。次のセクションでの説明にあるように、属性用のビジネス オブジェクトを使用することで、スキーマへの依存度を低下できます。

CAD アプリケーションレイヤは com.osm.datamgmt.biz パッケージにあるオブジェクトによって実装されます。詳細については、Creo Elements/Direct Model Manager の内部アーキテクチャを参照してください。

次の 2 つのシナリオについて検討します。パートナー A とパートナー B の 2 社がカスタマイズを開発しました。カスタマ C が、パートナー A 社およびパートナー B 社の両方のカスタマイズを使用したいと考えています。2 つのカスタマイズには機能面での重複はありません。

最初のシナリオでは、パートナー A 社およびパートナー B 社はいずれも MODEL_3D を拡張しました。このケースでは、以下のような XML ファイルのコードを使用して、カスタマイズがクラスを拡張しています。

番目のシナリオでは、パートナー A 社およびパートナー B 社はいずれも、MODEL_3D 用の新規の属性 (擬似属性) を定義し、その新規属性用のビジネスオブジェクトを作成しました。機能は重複しないため、2 つのカスタマイズが同じ属性名を使用することはありません。以下のような XML ファイルのコードによって、カスタマイズが属性用のビジネス オブジェクトを作成していることを確認できます。

最初のシナリオでは、カスタマ C が両方のカスタマイズを使用できるように、Java 開発者が 2 つのカスタマイズの Java コードを統合する必要があります。たとえば、パートナー A のコードを編集してパートナー B のクラスを継承 (またはその逆) し、その後で問題があれば解決を行う必要があります。

2 番目のシナリオでは、XML ファイルの属性定義を統合することによって、カスタマー C は両方のカスタマイズを使用できます。Java コードの変更は必要ありません。

クラスを拡張せずに属性のビジネス オブジェクトを使用することで、カスタマイズの統合に関するほとんどの問題を解決し、最も普遍性の高いカスタマイズを作成することができます。また、拡張のガイドラインの説明にあるように、リスナーを使用することによっても、スキーマの独立性を高いレベルで提供できます。