抽象と実装の設計パターン
抽象と実装の設計パターンでは、標準設計パターンの抽象部分は、それ独自の構築ブロック (PTC.BuildingBlock など) に分割され、実装構築ブロック (PTC.BuildingBlockImpl など) から分離されます。これにより、ソリューション開発者は、同じ抽象構築ブロックの複数の実装 (PTC.BuildingBlockImpl1 や PTC.BuildingBlockImpl2 など) を提供できるようになります。
抽象構築ブロックでは、管理 Thing Shape (PTC.BuildingBlock.Management_TS など) でのサービス定義は、実装構築ブロックでオーバーライドされることを意図した、空のオーバーライド可能なサービスです。実装構築ブロックには、追加のマネージャ実装 Thing Template (PTC.BuildingBlockImpl.Manager_TT など) があります。このマネージャ Thing Template は、抽象構築ブロック内のマネージャ Thing Template から拡張され、管理 Thing Shape で定義されているサービスを継承します。そのサービスは、実装構築ブロックマネージャ Thing Template に実際に実装されています。
次の図は、構築ブロックに必要なエンティティが、抽象と実装の構築ブロックに分割される方法を示しています。
この図において、中空の頭部と実線の矢印 (
) は、矢印が指しているエンティティからエンティティが拡張していること、中空の頭部と破線の矢印 (
) は、矢印が指しているエンティティをエンティティが実装していることをそれぞれ示します。
) は、矢印が指しているエンティティからエンティティが拡張していること、中空の頭部と破線の矢印 () は、矢印が指しているエンティティをエンティティが実装していることをそれぞれ示します。必要なエンティティ
抽象と実装の設計パターンでは、次のエンティティが必要です。
• プロジェクト - 各構築ブロック (抽象と実装) には、構築ブロックエンティティ (PTC.BuildingBlock や PTC.BuildingBlockImpl など) を含む ThingWorx プロジェクトエンティティがあります。推奨される命名規則では、構築ブロックの一部であるすべてのエンティティの名前に、プロジェクト名が含まれています。
• エントリポイント - エントリポイントは、名前、バージョン、依存などを含む、インストールされているソリューションの残りの部分に対する構築ブロックを識別します。構築ブロックが ThingWorx サーバーに最初にデプロイされたときは、DeployComponent という名前のサービスをオーバーライドして、アクションを実行できます。
抽象構築ブロックは、独自のエントリポイント Thing Template (PTC.BuildingBlock.EntryPoint_TT など) 用に、PTC.Base.ComponentEntryPoint_TT Thing Template を拡張します。実装構築ブロックは、独自のエントリポイント Thing Template (PTC.BuildingBlockImpl.EntryPoint_TT など) 用に、PTC.DefaultConfiguration.EntryPoint_TT Thing Template を拡張します。
エントリポイント Thing は、構築ブロックごとに、そのエントリポイント Thing Template (PTC.BuildingBlock.EntryPoint および PTC.BuildingBlockImpl.EntryPoint など) からそれぞれ作成されます。
• マネージャ - 構築ブロックマネージャは、構築ブロックのプライマリサービスレイヤーであり、構築ブロックに複数の機能を提供します。まず、構築ブロックに対して呼び出しを行うエンティティの抽象レイヤーとして動作します。次に、メニューアイテム、組み込みマッシュアップ、および複数が定義されている場合に使用するマネージャを設定するために使用します。
抽象構築ブロックには、PTC.Base.CommonManager_TT から拡張されたマネージャ Thing Template (PTC.BuildingBlock.Manager_TT) が必要です。実装構築ブロックには、抽象構築ブロックのマネージャ Thing Template から拡張されたマネージャ Thing Template (PTC.BuildingBlockImpl.Manager_TT) があります。実装構築ブロックのマネージャ Thing は、実装構築ブロックのマネージャ Thing Template に基づいて作成されます。
また、抽象構築ブロックのマネージャ Thing Template には、実装された管理 Thing Shape (PTC.BuildingBlock.Management_TS) もあります。この Thing Shape には、コンポーネントに必要なすべてのサービスが含まれています。これらのサービスは、実際のサービス実装が存在する、実装構築ブロックマネージャ Thing Template によって継承されます。PTC によって開発された構築ブロックの場合、これらのサービスはカスタマイズとしてオーバーライドできるため、ソリューション開発者は、独自の目的のために、デフォルトのサービスをオーバーライドできるようになります。詳細については、サービスのカスタマイズを参照してください。
実装構築ブロックのマネージャ Thing Template では、その実装に必要な追加の Thing Shape を実装できます。たとえば、DPM ソリューションの多数の実装構築ブロックは、PTC.DBConnection.DBManagement_TS Thing Shape を実装して、DPM データベースにアクセスできるようになります。
オプションのエンティティ
次の図は、抽象と実装の設計パターンに含めることができる、オプションのエンティティを示しています。次の図では、モデル、アセット、または設備階層を含む構築ブロックの例として PTC.MfgModel 構築ブロックが使用されており、それらの Thing Template では、抽象と実装の設計パターンの構築ブロックにモデルロジック Thing Shape が実装されています。外形が破線のエンティティは、以下で説明する特定の目的用として、このパターンに含まれるオプションのエンティティです。抽象と実装の設計パターンには、その他の ThingWorx エンティティも含めることはできますが、それらのエンティティには特定の意味があります。
この図において、中空の頭部と実線からなる矢印 () は、矢印が指しているエンティティからエンティティが拡張していること、中空の頭部と破線からなる矢印 () は、矢印が指しているエンティティをエンティティが実装していることをそれぞれ示します。
) は、矢印が指しているエンティティからエンティティが拡張していること、中空の頭部と破線からなる矢印 () は、矢印が指しているエンティティをエンティティが実装していることをそれぞれ示します。抽象と実装の設計パターンには、以下のオプションのエンティティが含まれています。
• セキュリティエンティティ - アクセス許可ユーザーグループを作成および使用して、構築ブロックごとに異なるアクセス許可を定義できます。ユーザー役割は、各アクセス許可ユーザーグループに追加される、単なる別のユーザーグループです。
• マッシュアップ - 抽象と実装の設計パターンにより、構築ブロック機能の一部として、マッシュアップを追加できます。これらは、マスターマッシュアップに結び付けられるメインマッシュアップであるか、またはさまざまな構築ブロックで使用される組み込みマッシュアップである可能性があります。構築ブロックの開発者は、どの機能をどの構築ブロックに含めるかを決定する必要があります。
• モデルロジックエンティティ - モデルロジック Thing Shape は、マッシュアップやその他のコンポーネントで使用されることを目的としており、ThingWorx の要件に従って組織を使用することで、設備に組織のセキュリティを強制します。これは、ユースケースが個々の設備ごとに表示制御を呼び出す場合に必要です。モデルロジック Thing Shape に含まれるサービスは、設備の階層エンティティに適用され、構築ブロックの管理 Thing Shape を通じて適切に設定されたマネージャに対して呼び出しを行うための、ラップされたサービスを提供します。すべてのマネージャは、PTC.BaseManager Thing で、DefaultGlobalManagerConfiguration コンフィギュレーションテーブルに登録されます。マネージャは、PTC.Base.ConfigManagement_TS Thing Shape (構築ブロックのマネージャ Thing、または Thing Shape (PTC.MfgModel.DefaultWorkUnit_TT など) を実装する Thing Template に基づく設備モデル Thing など) を実装する、任意のエンティティの ManagerConfiguration コンフィギュレーションテーブルで設定することもできます。これにより、さまざまなモデルで異なるマネージャを使用できます。たとえば、2 つのサイトでは、さまざまなソースからデータを取得するので、使用するマネージャが異なる場合があります。
あるサービスが別のマネージャを参照する場合は、まず、そのサービスを呼び出しているエンティティの ManagerConfiguration テーブルを調べて、参照されているマネージャに設定されているエントリがあるかどうかを確認します。そこにエントリが見つからない場合、サービスは次に、PTC.Base.Manager Thing の DefaultGlobalManagerConfiguration コンフィギュレーションテーブルを調べます。