Building block > Schemi di progettazione di building block > Schema di progettazione astratto e di implementazione
Schema di progettazione astratto e di implementazione
Nello schema di progettazione astratto e di implementazione, la parte astratta dello schema di progettazione standard viene suddivisa e formata nel proprio building block, ad esempio PTC.BuildingBlock, che è separato dal building block di implementazione, ad esempio PTC.BuildingBlockImpl. Ciò consente allo sviluppatore di soluzioni di fornire più implementazioni dello stesso building block astratto, ad esempio PTC.BuildingBlockImpl1, PTC.BuildingBlockImpl2 e così via.
Nel building block astratto, le definizioni dei servizi nella thing shape di gestione, ad esempio PTC.BuildingBlock.Management_TS, sono servizi vuoti che possono essere sostituiti nel building block di implementazione. Nel building block di implementazione è disponibile un modello di oggetto di implementazione manager aggiuntivo, ad esempio PTC.BuildingBlockImpl.Manager_TT. Questo modello di oggetto manager si estende dal modello di oggetto manager del building block astratto, ereditando i servizi definiti nella thing shape di gestione. I servizi vengono effettivamente implementati nel modello di oggetto manager dei building block di implementazione.
Il diagramma seguente mostra la suddivisione delle entità obbligatorie per un building block in building block astratti e di implementazione:
Diagramma che mostra le entità obbligatorie per un building block suddiviso in un building block astratto e di implementazione, comprese le entità implementate o estese da altre entità.
Nel diagramma, le frecce con punte vuote e linee continue () indicano che un'entità si estende dall'entità a cui punta la freccia, mentre le frecce con punte vuote e linee tratteggiate () indicano che un'entità implementa l'entità a cui punta la freccia.
Entità obbligatorie
Le entità seguenti sono obbligatorie nello schema di progettazione astratto e di implementazione:
Progetti - Ogni building block (astratto e di implementazione) presenta un'entità del progetto ThingWorx contenente le entità del building block, ad esempio PTC.BuildingBlock e PTC.BuildingBlockImpl. La convenzione di denominazione consigliata include il nome del progetto nei nomi di tutte le entità che fanno parte del building block.
Punto di entrata - Il punto di entrata identifica il building block rispetto al resto della soluzione installata, inclusi nome, versione, dipendenze e così via. È possibile sostituire un servizio denominato DeployComponent per eseguire un'azione quando il building block viene inizialmente distribuito nel server ThingWorx.
Il building block astratto estende il modello di oggetto PTC.Base.ComponentEntryPoint_TT per il proprio modello di oggetto punto di entrata, ad esempio PTC.BuildingBlock.EntryPoint_TT. Il building block di implementazione estende il modello di oggetto PTC.DefaultConfiguration.EntryPoint_TT per il proprio modello di oggetto punto di entrata, ad esempio PTC.BuildingBlockImpl.EntryPoint_TT.
Un oggetto punto di entrata viene creato per ogni building block dal relativo modello di oggetto punto di entrata, ad esempio PTC.BuildingBlock.EntryPoint e PTC.BuildingBlockImpl.EntryPoint rispettivamente.
Manager - Il manager del building block è il livello di servizio principale per il building block e fornisce più funzionalità per il building block. In primo luogo, funge da livello di astrazione per le entità che chiamano nel building block. In secondo luogo, viene utilizzato per configurare le voci di menu, i mashup incorporati e i manager da utilizzare quando ne vengono definiti più di uno.
Il building block astratto deve avere un modello di oggetto manager (PTC.BuildingBlock.Manager_TT) che si estende da PTC.Base.CommonManager_TT. Il building block di implementazione include un modello di oggetto manager (PTC.BuildingBlockImpl.Manager_TT) che si estende dal modello di oggetto manager del building block astratto. L'oggetto manager per il building block di implementazione viene creato in base al modello di oggetto manager del building block di implementazione.
Il modello di oggetto manager del building block astratto presenta inoltre una thing shape di gestione implementata (PTC.BuildingBlock.Management_TS). Questa thing shape contiene tutti i servizi necessari per il componente. Questi servizi vengono ereditati dal modello di oggetto manager del building block di implementazione, dove risiede l'implementazione del servizio effettivo. Per i building block sviluppati da PTC, questi servizi possono essere sostituiti nell'ambito della personalizzazione, consentendo agli sviluppatori di soluzioni di sostituire i servizi di default per i propri scopi. Per ulteriori informazioni, vedere Personalizzazione dei servizi.
Il modello di oggetto manager del building block di implementazione può implementare tutte le thing shape aggiuntive necessarie per l'implementazione. Ad esempio, molti building block di implementazione della soluzione DPM implementano la thing shape PTC.DBConnection.DBManagement_TS per poter accedere al database DPM.
Entità facoltative
Il diagramma riportato di seguito mostra le entità facoltative che possono essere incluse nello schema di progettazione astratto e di implementazione. Nel diagramma seguente il building block PTC.MfgModel viene utilizzato come esempio di building block con modello, asset o gerarchia impianti, i cui modelli di oggetto implementano la thing shape della logica del modello nel building block dello schema di progettazione astratto e di implementazione. Le entità con contorni tratteggiati sono entità facoltative incluse in questo schema per gli scopi specifici descritti di seguito. Nello schema di progettazione astratto e di implementazione è possibile includere anche altre entità ThingWorx, ma tali entità hanno un significato specifico.
Diagramma che mostra le entità obbligatorie e facoltative per un building block suddiviso in un building block astratto e di implementazione, comprese le entità implementate o estese da altre entità.
Nel diagramma, le frecce con punte vuote e linee continue () indicano che un'entità si estende dall'entità a cui punta la freccia, mentre le frecce con punte vuote e linee tratteggiate () indicano che un'entità implementa l'entità a cui punta la freccia.
Le seguenti entità facoltative sono incluse nello schema di progettazione astratto e di implementazione:
Entità di protezione - I gruppi di utenti dei permessi possono essere creati e utilizzati per definire permessi diversi per ciascun building block. Un ruolo utente è semplicemente un altro gruppo di utenti aggiunto a ogni gruppo di utenti dei permessi.
Mashup - Lo schema di progettazione astratto e di implementazione consente di aggiungere mashup come parte della funzionalità del building block. È possibile aggiungere mashup principali legati nel mashup master o mashup incorporati che vengono utilizzati da building block diversi. È compito dello sviluppatore del building block determinare quali funzionalità si trovano nei building block diversi.
Entità della logica del modello - La thing shape della logica del modello è destinata a essere utilizzata dai mashup o da altri componenti che applicano la protezione organizzativa per l'impianto utilizzando le organizzazioni come richiesto da ThingWorx. Questa operazione è necessaria se il caso di utilizzo richiede il controllo di visibilità per il singolo impianto. I servizi contenuti nella thing shape della logica del modello vengono applicati alle entità gerarchiche dell'impianto e forniscono servizi di wrapping da chiamare nel manager configurato appropriato tramite la thing shape di gestione per il building block. Tutti i manager sono registrati nella tabella di configurazione DefaultGlobalManagerConfiguration dell'oggetto PTC.BaseManager. I manager possono inoltre essere configurati nella tabella di configurazione ManagerConfiguration di qualsiasi entità che implementi la thing shape PTC.Base.ConfigManagement_TS, ad esempio l'oggetto manager per un building block o un oggetto modello di impianto basato su un modello di oggetto che implementa la thing shape (ad esempio PTC.MfgModel.DefaultWorkUnit_TT). In tal modo diversi modelli possono utilizzare diversi manager. Ad esempio, può essere utile utilizzare per due siti manager diversi perché ricevono dati da origini diverse.
Quando un servizio fa riferimento a un altro manager, il sistema esamina prima la tabella ManagerConfiguration dell'entità che chiama il servizio per verificare se è stata configurata una voce per il manager referenziato. Se non viene trovata alcuna voce, il servizio esamina la tabella di configurazione DefaultGlobalManagerConfiguration dell'oggetto PTC.Base.Manager.
È stato utile?