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. Der Wert 10.0 eines Datentyps
double
in C# beispielsweise besitzt keine weitere Identität, er ist einfach selbst ein Wert und weiß quasi selbst nichts über sich. Wann immer dieser Wert in einer Software vorkommt, es handelt sich stets um denselben Wert.
Datentypen dürfen gemäß dem Metamodell Operationen und Attribute enthalten. Der selbst erstellte Datentyp
Punkt
hat beispielsweise zwei Attribute
x
und
y
in einem Koordinatensystem, so wie man dies aus dem Mathematikunterricht kennt. Durch mathematische Formeln können zum Beispiel die Werte des Punktes und somit seine Verortung im Koordinatensystem verändert werden. In diesem Falle heißt dies aber nicht, dass die Werte
x
und
y
eine andere Identität erhalten. Der eigentliche Wert war 10.0 und nunmehr, durch die mathematische Operation, wird ein anderer Wert genommen.
Abbildung 1.2 zeigt einen einfachen Datentyp Punkt, der aus zwei Positionen zusammengesetzt wird:
Durch die Methode shiftPositionX kann nunmehr ein neuer Wert für x und mit der Methode shiftPositionY kann ein neuer Wert für y berechnet werden.
Bei den primitiven Datentypen hält natürlich die Programmiersprache
die einzelnen Datentypen bereit. Somit sind diese in jeder Programmiersprache
anders definiert. Die UML 2.0 selbst hält folgende primitive Datentypen bereit,
falls keine spezielle Programmiersprache gefordert ist:
Die UML 2.0 legt keine genauen Einschränkungen dieser Werte fest; diese sind bei den primitiven Datentypen also unbeschränkt. In einer konkreten Programmiersprache verhält sich dies natürlich anders.
Man darf hier weitere primitive Datentypen selbst einführen. Notiert werden die primitiven Datentypen mit der Klassennotation und dem Schlüsselwort
<<primitive>>.
Abbildung 1.3 zeigt einen primitiven Datentyp:
Bei den Aufzählungstypen, den Enumerations, handelt es sich um
einfache Datentypen, deren Werte keine Identität haben, also beispielsweise
nicht vom Typ Integer oder Ähnlichem sind. Eine Aufzählung ist dabei
prinzipiell eine Gruppe mehrerer Konstanten, die nicht mehr verändert werden
können. Es handelt sich um eine endliche Menge an Werten. In Spezialisierungen
kann diese Liste an Werten um weitere Werte ergänzt werden.
Ein einfacher Datentyp und ein primitiver Datentyp haben grundsätzlich nichts mit einer Klasse zu tun, sie haben lediglich eine gemeinsame Oberklasse Classifier. In einem späteren Abschnitt über das Metamodell soll dies noch deutlicher werden. Notiert werden die Aufzählungstypen mit
<<enumeration>>.
Ein Beispiel wären Schulnoten. Hier gibt es sechs verschiedene Noten, also von 1 bis 6. In Abbildung 1.4 sehen Sie diese Aufzählung.
Die in der UML 2.0 so genannten Stereotypen erweitern quasi ein Modellelement formal. Das Stereotyp gibt dabei Auskunft über die Nutzungsweise des Elementes und teilt es in eine entsprechende Kategorie ein. Die UML 2.0 bietet also die Möglichkeit an, die Sprache mit benutzerdefinierten zusätzlichen Eigenschaften zu ergänzen. Es sind bei einem Modellelement durchaus gleichzeitig mehrere Stereotypen erlaubt. Daneben ist es ebenfalls erlaubt, Attribute und Operationen mit Stereotypen zu versehen.
Die Notation erfolgt über den Namen des Stereotyps, der in folgenden Zeichen eingeschlossen ist:
<<Name>>.
Häufig wird dies mit den Schlüsselwörtern in der UML 2.0 selbst verwechselt, die ebenfalls mit dieser Notation einhergehen.
Tabelle 1.1 zeigt einige Stereotypen der UML 2.0
| Stereotyp | Beschreibung |
|---|---|
| auxiliary | Dienen der Implementierung weiterer Logik für eine andere Klasse. Sie dienen den Focus-Klassen, wobei focus ebenfalls ein Stereotyp ist (siehe unten). |
| call | Eine Usage-Beziehung, genannt call, besitzt am Ende Operationen, die sich auf die Assoziation beziehen. |
| create | Bei einer Usage-Beziehung bedeutet create, dass ein Objekt ein anderes erzeugt. Eine zweite Möglichkeit ist die Nutzung bei Operationen. Hierbei würde die Operation eine Instanz erzeugen. |
| derive | Das Stereotyp derive besagt, dass die verbundenen Modellelemente voneinander abgeleitet sind. Damit sind sie naturgemäß auch vom gleichen Typ. |
| destroy | Das Stereotyp destroy besagt genau das Gegenteil des Stereotyps create. Somit bedeutet es die Zerstörung eines Objektes. |
| focus | Gibt an, dass sich die Hauptlogik in dieser Klasse befindet. |
| implementation class | Es handelt sich dabei um implementierte Klassen einer spezifischen Programmiersprache. |
| instantiate | Dieses Stereotyp kann an einer Usage-Beziehung angebracht werden und dort dafür Sorge tragen, dass eine Instanz entsteht. |
| interface | Dieses Stereotyp gibt an, dass es sich um ein Interface, also eine Schnittstelle, handelt. |
| enumeration | Es handelt sich um einen Aufzählungstyp. Die möglichen Werte werden als Attribute ohne Datentyp angegeben. |
| responsibility | Ein Element ist damit verantwortlich für ein anderes Element. Das Element, das diese Verantwortung übernimmt, geht quasi einen Vertrag mit dem Zielelement ein. |
| send | Bei einer Usage-Beziehung sendet die Quelle ein Signal. |
| substitute | Das Stereotyp substitute sagt aus, dass dieses Objekt durch ein anderes Objekt einer abgeleiteten Klasse ersetzt werden kann. |
| trace | Dieses Stereotyp wird verwendet, um Änderungen zwischen den verschiedenen Modellelementen nachverfolgen zu können. |
| type | Mit diesem Stereotyp wird angegeben, dass eine Anzahl von Operationen geordnet zur Verfügung gestellt wird. Meistens sind diese Operationen dann abstrakt. |
| utility | Es können von einer Klasse, die mit dem Stereotyp utility gekennzeichnet ist, keine Objekte instanziert werden. Somit stellt eine solche Klasse entsprechend statische Hilfsmethoden zur Verfügung. |
Tabelle 1.1: Stereotypen
Die Anwendungen, in denen man Stereotypen findet, können sehr vielfältig gestaltet sein. Selbst eine Klasse in der UML 2.0 ist jederzeit im Prinzip voreingestellt mit dem Stereotyp class.
Diagramme in der UML 2.0 haben zumeist eine Darstellung wie in Abbildung 1.6.
Ein Diagramm wird grundsätzlich in der UML 2.0 in einem Rechteck notiert. Darin enthalten sind die eigentlichen Elemente. Im Diagrammkopf steht zunächst der Typ des Diagramms gefolgt von dem Namen. Es können aber auch optional Parameter enthalten sein.
comelio.com
