Fußnoten zu Kapitel 4

1 Gemäß der Java-Form wäre Typ name üblich. Jedoch ist dann aufgrund des fehlenden Doppelpunkts die optionale Auslassung des Objektnamens name oder des Typs Typ nicht mehr eindeutig erkennbar. Deshalb wurde die Schreibweise mit dem Doppelpunkt aus dem UML-Standard übernommen.

2 Wir ignorieren hier dynamisches Nachladen von Klassen. Außerdem können Objektstrukturen ihre Links dynamisch verändern. Dadurch können unbeschränkt viele Variationen von Objektstrukturen entstehen, die normalerweise nicht vollständig dargestellt werden können.

3 Gelegentlich werden nicht nur Objektdiagramme (in der jeweiligen syntaktischen Form), sondern auch ihre Erweiterung um Aufrufstrukturen, in Form von Kommunikationsdiagrammen, eingesetzt. Die im Objektdiagramm dargestellte Situation muss im tatsächlich ablaufenden System nicht auftreten. Sie kann jedoch auch mehr als einmal, zeitlich aufeinanderfolgend oder zur gleichen Zeit auftreten. In jeder der auftretenden Situationen können unterschiedliche oder auch (teilweise) dieselben Objekte beteiligt sein. Objektdiagramme können also im System überlappende Strukturen darstellen. Deshalb ist zwischen der Darstellung eines Objekts im Objektdiagramm und den echten Objekten eines Systems deutlich zu unterscheiden. Die in den Objektdiagrammen dargestellten Objekte werden daher auch als prototypisch bezeichnet.

4 Um eine syntaktische Korrektheit des Vergleichs zu erreichen, ist gegebenenfalls der Typ des ersten Objekts geeignet zu konvertieren.5

5 Da a von Typ Auktion und timePol vom Typ TimingPolicy sind, scheint es, dass beide Objekte ohnehin unterschiedlich sein müssen. Es kann jedoch der Fall eintreten, dass im Verlauf des Projekts eine Unterklasse von Auktion entwickelt wird, die das Interface TimingPolicy selbst implementiert. Dann ist die Ungleichung nicht mehr redundant.

6 In Welcome1 ist das Objekt timePol allquantifiziert, da es über die Implikation nach außen gezogen wurde. Es gilt hier ∀a : (X⇒Y ) ist äquivalent zu (∃a : X)⇒Y , da Y von a unabhängig ist. :

Bernhard Rumpe. Modellierung mit UML. Springer 2011

Fußnoten Kap. 1 Fußnoten Kap. 2 Fußnoten Kap. 3 Fußnoten Kap. 4 Fußnoten Kap. 5 Fußnoten Kap. 6 Fußnoten Kap. A Fußnoten Kap. B Fußnoten Kap. C		Fußnoten zu Kapitel 4 1 Gemäß der Java-Form wäre Typ name üblich. Jedoch ist dann aufgrund des fehlenden Doppelpunkts die optionale Auslassung des Objektnamens name oder des Typs Typ nicht mehr eindeutig erkennbar. Deshalb wurde die Schreibweise mit dem Doppelpunkt aus dem UML-Standard übernommen. 2 Wir ignorieren hier dynamisches Nachladen von Klassen. Außerdem können Objektstrukturen ihre Links dynamisch verändern. Dadurch können unbeschränkt viele Variationen von Objektstrukturen entstehen, die normalerweise nicht vollständig dargestellt werden können. 3 Gelegentlich werden nicht nur Objektdiagramme (in der jeweiligen syntaktischen Form), sondern auch ihre Erweiterung um Aufrufstrukturen, in Form von Kommunikationsdiagrammen, eingesetzt. Die im Objektdiagramm dargestellte Situation muss im tatsächlich ablaufenden System nicht auftreten. Sie kann jedoch auch mehr als einmal, zeitlich aufeinanderfolgend oder zur gleichen Zeit auftreten. In jeder der auftretenden Situationen können unterschiedliche oder auch (teilweise) dieselben Objekte beteiligt sein. Objektdiagramme können also im System überlappende Strukturen darstellen. Deshalb ist zwischen der Darstellung eines Objekts im Objektdiagramm und den echten Objekten eines Systems deutlich zu unterscheiden. Die in den Objektdiagrammen dargestellten Objekte werden daher auch als prototypisch bezeichnet. 4 Um eine syntaktische Korrektheit des Vergleichs zu erreichen, ist gegebenenfalls der Typ des ersten Objekts geeignet zu konvertieren.5 5 Da a von Typ Auktion und timePol vom Typ TimingPolicy sind, scheint es, dass beide Objekte ohnehin unterschiedlich sein müssen. Es kann jedoch der Fall eintreten, dass im Verlauf des Projekts eine Unterklasse von Auktion entwickelt wird, die das Interface TimingPolicy selbst implementiert. Dann ist die Ungleichung nicht mehr redundant. 6 In Welcome1 ist das Objekt timePol allquantifiziert, da es über die Implikation nach außen gezogen wurde. Es gilt hier ∀a : (X⇒Y ) ist äquivalent zu (∃a : X)⇒Y , da Y von a unabhängig ist. : Bernhard Rumpe. Modellierung mit UML. Springer 2011