Ein Muster, das dieser Artikel als Beispiel für den Einsatz von Schnittstellen vorstellen will, ist das Kompositum-Muster. Hier soll das Ziel umgesetzt werden, dass man Einheiten und zusammengesetzte Einheiten / Komposita unterscheidet. Das heißt, Objekte können wiederum andere Objekte enthalten. Dies ist, wenn man einen Warenkorb mit verschiedenen Produkt-Objekten zum Vergleich heranzieht, zunächst nicht so eine herausragende Besonderheit. Dies liegt an der grundsätzlichen Verschiedenheit von Warenkorb und Produkt. Eine weitere Voraussetzung, die in Situation, in welcher das Muster zum Einsatz kommen kann, zutreffen muss, ist die gleichartige Verarbeitung vom Kompositum und den einzelnen Einheiten.

Für die Bereitstellung von XML-Strukturen auf Basis von relationalen oder auch bereits vorhandenen XML-Daten lassen sich individuelle Abfragen gestalten. Wenn allerdings Abfragen in Anwendungen mehrfach ausgeführt werden sollen oder spezielle Rechte berücksichtigt werden müssen, eignen sich vorgefertigte Sichten auf die Daten. Diese lassen sich mit Hilfe des speziellen Datentyps XMLType auch in so genannten XMLType-Sichten erstellen, die gewöhnlichen Sichten ähneln und in diesem Artikel beispielhaft vorgestellt werden sollen.

Im Wesentlichen unterscheidet die UML 2.0 zwischen einfachen Datentypen, primitiven Datentypen und Aufzählungstypen, wie man in dem Metamodell sehen kann. Dabei ist der Begriff »einfacher Datentyp« der Oberbegriff der primitiven Datentypen und der Aufzählungstypen, der so genannten Enumerations. Ein einfacher Datentyp ist ein Typ, dessen Werte keine Identität haben. Hier ist genau der Unterschied zu einer Klasse zu sehen. Jedes Objekt einer Klasse unterscheidet sich eindeutig und besitzt eine eigene Identität. Werte eines Datentyps hingegen kann man nicht voneinander unterscheiden.

Komplexe Zerlegung mit XPath

Sobald man keine eigene Entscheidung über das XML-Format treffen kann, die angeliefer-ten Daten tief verschachtelt sind und fast gar nicht den benötigten relationalen Strukturen entsprechen, genügt die einfache Zuordnung nicht mehr und man muss auf die Möglichkeit zurückgreifen, die genaue Zuordnung mit Hilfe von XPath-Ausdrücken auszuführen. Das in der nächsten Abfrage erzeugte XML-Dokument bietet einen solchen komplexen Aufbau. Innerhalb der sich wiederholenden Product-Elemente gibt es ein Attribut für die Produkt-nummer, ein Kind-Element für den Namen mit einem Textknoten sowie zwei weitere Kin-der, die selbst wieder Kinder für Preis- und Detailinformationen besitzen.

<Product-List>

  <Product ProductNumber="BK-R19B-52">

  <Name>Road-750 Black, 52</Name>

  <Prices>

  <Standard>343.6496</Standard>

  <List>539.9900</List>

  </Prices>

  <Details>

  <Size>52</Size>

  <Color>Black</Color>

  </Details>

  </Product>

  </Product-List>
  

Mit den Verhaltensdiagrammen werden im Wesentlichen die einzelnen Elemente und deren Veränderungen zur Laufzeit beschrieben. Mit den Verhaltensdiagrammen der UML 2.0 soll also Klarheit über die Geschäftsprozesse, internen Abläufe, des Zusammenspiels des Systems und vieles mehr geschaffen werden. Es geht sozusagen um die Veränderungen der einzelnen Classifier eines Systems zur Laufzeit. Für diese Veränderungen gibt es verschiedene Diagrammtypen, die jeweils einen anderen Aspekt genauer beleuchten. Da die UML 2.0 komplett objektorientiert ist, gibt es immer nur Objekte, die ihre Zustände durch Verhalten ändern. Verhalten ist sozusagen beobachtbar, man kann sich also die Eigenschaften der beteiligten Elemente im Verlauf der Zeit ansehen und die Veränderungen beobachten.