Bausteine > Entwurfsmuster für Bausteine > Abstrakte Entwurfsmuster und Implementierungs-Entwurfsmuster
Abstrakte Entwurfsmuster und Implementierungs-Entwurfsmuster
In den abstrakten Entwurfsmustern und den Implementierungs-Entwurfsmustern wird der abstrakte Teil des Standard-Entwurfsmusters aufgeteilt und in einen eigenen Baustein gebildet, z.B. PTC.BuildingBlock, der vom Implementierungs-Baustein getrennt ist, z.B. PTC.BuildingBlockImpl. Dies ermöglicht es dem Lösungsentwickler, mehrere Implementierungen des gleichen abstrakten Bausteins bereitzustellen, z.B. PTC.BuildingBlockImpl1, PTC.BuildingBlockImpl2 usw.
Im abstrakten Baustein sind die Dienstdefinitionen in der Verwaltungs-Dingform, z.B. PTC.BuildingBlock.Management_TS leere, überschreibbare Dienste, die im Implementierungs-Baustein überschrieben werden. Im Implementierungs-Baustein gibt es eine zusätzliche Manager-Implementierungs-Dingvorlage, z.B. PTC.BuildingBlockImpl.Manager_TT. Diese Manager-Dingvorlage erweitert die Manager-Dingvorlage im abstrakten Baustein und erbt die in der Verwaltungs-Dingform definierten Dienste. Die Dienste sind in der Manager-Dingvorlage für Implementierungs-Bausteine implementiert.
Das folgende Diagramm zeigt, wie die erforderlichen Entitäten für einen Baustein in abstrakte Bausteine und Implementierungs-Bausteine aufgeteilt werden.
Diagramm mit den erforderlichen Entitäten für einen Baustein, der in einen abstrakten Baustein und einen Implementierungs-Baustein unterteilt ist, einschließlich der Entitäten, die von anderen Entitäten implementiert werden oder die aus anderen Entitäten hervorgehen
Im Diagramm weisen Pfeile mit hohlen Köpfen und durchgezogenen Linien () darauf hin, dass sich eine Entität von der Entität aus erweitert, auf die der Pfeil zeigt, und Pfeile mit hohlen Köpfen und gestrichelten Linien () weisen darauf hin, dass eine Entität die Entität implementiert, auf die der Pfeil zeigt.
Erforderliche Entitäten
Die folgenden Entitäten sind in den abstrakten Entwurfsmustern und den Implementierungs-Entwurfsmustern erforderlich:
Projekte – Jeder Baustein (abstrakte Bausteine und Implementierungs-Bausteine) hat eine ThingWorx Projektentität, die die Bausteinentitäten enthält, z.B. PTC.BuildingBlock und PTC.BuildingBlockImpl. Die empfohlene Namenskonvention enthält den Projektnamen in den Namen aller Entitäten, die Teil des Bausteins sind.
Einstiegspunkt – Der Einstiegspunkt identifiziert den Baustein für den Rest der installierten Lösung, einschließlich Name, Version, Abhängigkeiten usw. Der Dienst DeployComponent kann überschrieben werden, um eine Aktion auszuführen, wenn der Baustein zuerst auf dem ThingWorx Server bereitgestellt wird. Der abstrakte Baustein erweitert die Dingvorlage PTC.Base.ComponentEntryPoint_TT für seine eigene Einstiegspunkt-Dingvorlage, z.B. PTC.BuildingBlock.EntryPoint_TT. Der Implementierungs-Baustein erweitert die Dingvorlage PTC.DefaultConfiguration.EntryPoint_TT für seine eigene Einstiegspunkt-Dingvorlage, z.B. PTC.BuildingBlockImpl.EntryPoint_TT. Ein Einstiegspunkt-Ding wird für jeden Baustein aus seiner Einstiegspunkt-Dingvorlage erstellt, z.B. PTC.BuildingBlock.EntryPoint und PTC.BuildingBlockImpl.EntryPoint.
Manager – Der Baustein-Manager ist die primäre Dienstschicht für den Baustein und bietet mehrere Funktionen für den Baustein. Zuerst fungiert er als Abstraktionsschicht für Entitäten, die den Baustein aufrufen. Zweitens wird er zum Konfigurieren von Menüoptionen und enthaltenen Mashups sowie der Information welche Manager verwendet werden sollen, wenn mehr als einer definiert ist.
Der abstrakte Baustein sollte eine Manager-Dingvorlage (PTC.BuildingBlock.Manager_TT) haben, die PTC.Base.CommonManager_TT erweitert. Der Implementierungs-Baustein hat eine Manager-Dingvorlage (PTC.BuildingBlockImpl.Manager_TT), die die Manager-Dingvorlage des abstrakten Bausteins erweitert. Das Manager-Ding für den Implementierungs-Baustein wird basierend auf der Manager-Dingvorlage des Implementierungs-Bausteins erstellt.
Die Manager-Dingvorlage des abstrakten Bausteins hat auch eine Verwaltungs-Dingform (PTC.BuildingBlock.Management_TS) implementiert. Diese Dingform enthält alle Dienste, die für die Komponente benötigt werden. Diese Dienste werden von der Manager-Dingvorlage für den Implementierungs-Baustein geerbt, in der sich die eigentliche Dienstimplementierung befindet. Für von PTC entwickelte Bausteine können diese Dienste als Anpassung überschrieben werden, sodass Lösungsentwickler Standarddienste für ihre eigenen Zwecke überschreiben können. Weitere Informationen finden Sie unter .
Die Manager-Dingvorlage des Implementierungs-Bausteins kann alle zusätzlichen Dingformen implementieren, die für diese Implementierung erforderlich sind. Beispielsweise implementieren viele Implementierungs-Bausteine in der DPM Lösung die Dingform PTC.DBConnection.DBManagement_TS, sodass sie auf die DPM Datenbank zugreifen können.
Optionale Entitäten
Das folgende Diagramm zeigt optionale Entitäten an, die in die abstrakte Entwurfsmuster und die Implementierungs-Entwurfsmuster eingeschlossen werden können. Im folgenden Diagramm wird der Baustein PTC.MfgModel als Beispiel für einen Baustein mit Modell-, Asset- oder Anlagenhierarchie verwendet, dessen Dingvorlagen die Modelllogik-Dingform im Baustein für die abstrakten Entwurfsmuster und die Implementierungs-Entwurfsmuster implementieren. Entitäten mit gestrichelten Umrissen sind optionale Entitäten, die in diesem Muster für die nachfolgend beschriebenen spezifischen Zwecke enthalten sind. Andere ThingWorx Entitäten können auch in die abstrakte Entwurfsmuster und die Implementierungs-Entwurfsmuster eingeschlossen werden. Diese Entitäten haben jedoch eine bestimmte Bedeutung.
Diagramm mit den erforderlichen und optionalen Entitäten für einen Baustein, der in einen abstrakten Baustein und einen Implementierungs-Baustein unterteilt ist, einschließlich der Entitäten, die von anderen Entitäten implementiert werden oder die aus anderen Entitäten hervorgehen
Im Diagramm weisen Pfeile mit hohlen Köpfen und durchgezogenen Linien () darauf hin, dass sich eine Entität von der Entität aus erweitert, auf die der Pfeil zeigt, und Pfeile mit hohlen Köpfen und gestrichelten Linien () weisen darauf hin, dass eine Entität die Entität implementiert, auf die der Pfeil zeigt.
Die folgenden optionalen Entitäten sind in den abstrakten Entwurfsmustern und den Implementierungs-Entwurfsmustern enthalten:
Sicherheits-Entitäten – Berechtigungs-Benutzergruppen können erstellt und verwendet werden, um unterschiedliche Berechtigungen für jeden Baustein zu definieren. Eine Benutzerrolle ist einfach eine weitere Benutzergruppe, die jeder Berechtigungs-Benutzergruppe hinzugefügt wird.
Mashups – Die abstrakte Entwurfsmuster und die Implementierungs-Entwurfsmuster ermöglichen das Hinzufügen von Mashups als Teil der Bausteinfunktionalität. Dies können Haupt-Mashups sein, die mit dem Master-Mashup verbunden sind, oder enthaltene Mashups, die von verschiedenen Bausteinen verwendet werden. Der Baustein-Entwickler bestimmt, welche Funktionen in welchem Baustein sind.
Modelllogik-Entitäten – Die Modelllogik-Dingform ist für die Verwendung durch Mashups oder andere Komponenten vorgesehen, die Organisationssicherheit für Anlagen erzwingen, indem die Organisationen nach Bedarf von ThingWorx verwendet werden. Dies ist erforderlich, wenn der Anwendungsfall die Sichtbarkeitssteuerung für einzelne Anlagen erfordert. Die Dienste, die in der Modelllogik-Dingform enthalten sind, werden auf die hierarchischen Entitäten der Anlage angewendet und bieten ein Wrapper für Dienste, um den entsprechenden konfigurierten Manager über die Verwaltungs-Dingform für den Baustein aufzurufen. Alle Manager sind in der Konfigurationstabelle DefaultGlobalManagerConfiguration auf dem Ding PTC.BaseManager registriert. Manager können auch in der Konfigurationstabelle ManagerConfiguration jeder Entität konfiguriert werden, die die Dingform PTC.Base.ConfigManagement_TS implementiert, z.B. das Manager-Ding für einen Baustein oder ein Anlagenmodellding, das auf einer Dingvorlage basiert, die die Dingform (z.B. PTC.MfgModel.DefaultWorkUnit_TT) implementiert. Dies ermöglicht es unterschiedlichen Modellen, verschiedene Manager zu verwenden. Beispielsweise können zwei Standorte unterschiedliche Manager haben, die sie verwenden möchten, da sie Daten aus verschiedenen Quellen erhalten.
Wenn ein Dienst einen anderen Manager referenziert, sucht er zuerst die Tabelle ManagerConfiguration der Entität, die den Dienst aufruft, um festzustellen, ob ein Eintrag für den referenzierten Manager konfiguriert ist. Wenn dort kein Eintrag gefunden wird, sucht der Dienst in der Konfigurationstabelle DefaultGlobalManagerConfiguration im Ding PTC.Base.Manager.
War dies hilfreich?