...

Regeln zum Anlegen von Typen, Meanings und Properties

...

So allgemein wie möglich und so spezifisch wie nötig

...

Alle Facility-Typen und ihre Elemente Elemente so allgemein wie möglich zu gestalten, bedeutet, dass sie für so viele Anwendungsfälle wie möglich einsetzbar sind. Beispiel: Das bedeutet, dass zum Beispiel der Typ "Equipment" als übergeordneter ein Typ so gestaltet sein muss, dass seine dazugehörigen Properties und dazugehörigen Meanings auf so viele Facilities wie möglich übertragbar sind. Durch einen solchen Aufbau kann der Facility-Typ für viele Facilities genutzt werden und kann gleichzeitig problemlos Properties und Meanings an zahlreiche untergeordnete Facility-Typen vererben. 

Beispiel: Facility "Büro" einrichten geht als Facility-Typ "Raum", weil es ein Raum ohne besondere Anforderungen ist

Die Facility-Typen und ihre Elemente sollten dennoch so spezifisch wie nötig beschrieben werden! Es sollte zwar universell einsetzbar sein, aber trotzdem so spezifisch gestaltet, dass es optimal zu seinem Anwendungsbereich passt.

Beispiel: "Kühlkammer" hat mehr Anforderungen als in "Raum" gegeben sind, deshalb verdient es einen eigenen Typen

"Temperatur" wäre as meaning Meaning beispielsweise zu allgemein gehalten, weil man als Anwender nicht weiß, welche Temperatur damit gemeint ist. An einem Standort könnte es ja sowohl die Außentemperatur, als auch die einzelner Räume sein. Die Meanings müssen also einzeln angelegt werden, um bestmöglich benutzt werden zu können. 

...

Kontrolliere, ob ein neuer Type wirklich notwendig ist!

Einige Facilities sind so spezifisch, dass es notwendig ist, einen eigenen Typen für sie anzulegen, weil sie Einstellungen benötigen, die so nicht durch andere Typen abgedeckt werden. Ist dies nicht der Fall, dann sollte kein neuer Facility-Typ angelegt werden! 

Beispiel: Soll eine Kaffeemaschine als Facility angelegt werden, dann ist es durchaus möglich, dass alle dafür notwendigen Eigenschaften wie "Hersteller"  oder "Garantie bis" bereits am Typen "Equipment" hinterlegt sind. Erst wenn eine Kombination aus Eigenschaften benötigt wird, die so an keinem anderen Typen zu finden sind, sollte ein neuer Typ angelegt werden, Dann kann dieser Facility-Typ für die Kaffeemaschine benutzt werden. Wird eine neue Eigenschaft benötigt, wie zum Beispiel "Sorte der Kaffeebohnen", sollte ein neuer Typ angelegt werden. 

...

Nutze die Vererbung weise!

Eigenschaften werden immer vollständig von übergeordneten an untergeordnete Facility-Typen vererbt. So können allgemeine Eigenschaften an speziellen Typen wiederverwendet werden. Deshalb sollten Sie so weit oben wie möglich den der Hierarchie eingesetzt werden wie möglich. 

Beispiel: Beim Facility-Typen "Elektrozähler (manuell) gibt es wird die Eigenschaft "Geeicht bis" benötigt. Diese Eigenschaft wäre aber findet auch für an den übergeordneten Typen "Elektrozähler" verwendbar, ebenso wie am weiter oben stehenden Typen "Zähler" und all seinen anderen untergeordneten Facility-Typen Verwendung. Es ergibt jedoch keinen Sinn, die Eigenschaft beim Typen "Equipment" anzubringen, da sie nicht für alle dort untergeordneten Typen gilt. "Geeicht bis" sollte demzufolge beim höchstmöglichen Typen "Zähler" angebracht werden, da es sinnvoll auf alle untergeordneten Typen vererbt werden kann. 

Ein neues Meaning sollte erstellt werden, wenn Daten unabhängig von bereits existierenden Meanings aggregiert werden sollen. 

Nutze Meanings um Daten zu separieren!

Wenn es notwendig ist, Daten separiert voneinander zu aggregieren, werden auch separate Meanings benötigt. 

Beispiel: 

• z.B. Lastgang Erdgas/ Elektro/ etc.

Hinweise zu

...

Eigenschaften 

...

Gruppiere Eigenschaften sinnvoll!

Eine sinnvolle Gruppierung von Properties macht die Eigenschaftenseite an Facilities übersichtlicher, hilft dem Nutzer dabei, diese einzutragen und zuzuordnenerleichtert die Zuordnung. 

Ein Element sollte als "searchable" markiert werden, wenn es sinnvoll ist, danach suchen zu können. 

Beispiel: Technische Daten eigene Gruppe, Allgemeines eigene, Abmessungen eigene, vor allem sinnvoll bei vielen Eigenschaften

Vereinfache die Facility-Suche!

Ist eine Eigenschaft Ist ein Element als "searchable" markiert, dann kann es deren zugehörige Facility in QBRX über die Suche gefunden werden. Eigenschaften sollten als "searchable" markiert werden, wenn es dabei hilft, facilities zu finden. Es sollte jedoch nicht jede Eigenschaft markiert werden, da sonst unnötig viele Suchergebnisse geliefert werden. Die Funktion sollte auch nur bei Eigenschaften verwendet werden, deren Wert eindeutig von anderen unterscheidbar ist.

Beispiel: Das ist zum Beispiel bei Adressen von Standorten oder Herstellern von Ausrüstungsteilen sind beispielsweise sinnvoll. 

Wo noch? Wann nicht?

Benennung

...

Namen

...

konsistent und eindeutig

...

wählen!

Eine eindeutige Benennung von Elementen erleichtert es dem Nutzer, den richtigen Facility-Typen und dessen Elemente auszuwählen und danach zu filtern. Dabei sollte auch eine gewisse Konsistenz eingehalten werden, die sich an der Benennung der bisher existierenden Typen bzw. der entsprechenden Dokumentation orientiert. 

Namen sollten so allgemein wie möglich und so spezifisch wie nötig gewählt werden!

Was für die Gestaltung von Elementen gilt, gilt auch für deren Benennung: Elemente sollten so benannt werden, dass sie für viele Zwecke benutzt werden können, aber so spezifisch, dass klar wird, wofür genau sie da sind.

Beim Erstellen einer neuen Bibliothek sollte vorher eine Einigung zur Benennung getroffen und dokumentiert werden.

man sich an vorher festgelegte Konventionen halten um eine gewisse Konsistenz zu gewährleisten.

Eine neue Facility-Bibliothek erfordert das Anlegen vieler neuer Elemente. Damit diese eindeutig und konsistent benannt werden, sollte vorher eine dementsprechende Einigung getroffen werden, die in einer Dokumentation festgehalten wird. 

Das sollten wir auch mal machen  

Meanings müssen so benannt werden, dass sie unabhängig voneinander genutzt werden können.

Meanings sollten an so vielen Facilities wie möglich benutzt werden können und daher, wie alle anderen Elemente auch, zwar spezifisch, aber dennoch so allgemein wie möglich benannt werden. Dazu gehört auch, dass sie unabhängig voneinander funktionieren müssen.

Beispiel: Gibt es mehrere Temperaturen, die an einer Facility erfasst werden müssen, dann sollte diese eindeutig benannt werden. Beispiel mit den Temperaturen 1,2,3 erklären, wo kam das noch mal vor?

• Keine „Durchnummerierung“ von Meanings.
  • Z.B. Temperatur 1,2, 3, …

...

Abkürzungen vermeiden!

Es gibt Abkürzungen, die allgemein bekannt sind und von jedem verstanden werden, wie zum Beispiel "z.B.". Es gibt allerdings auch Abkürzungen, die zwar praktisch erscheinen, aber aufgrund ihrer Unbekanntheit oder Doppeldeutigkeit mehr Probleme verursachen als lösen. Nicht jeder kennt die Abkürzung "NTH" für "nice to have". Stattdessen könnte sie auch als "Nothing" oder "No Therapy Helpful" gedeutet werden. 

...