UML: Unterschied zwischen den Versionen

Aus Geoportal
(Die Seite wurde neu angelegt: „<translate> Diese Seiten befinden sich im Aufbau. Ziel ist ein Überblick über UML vor dem Hintergrund von INSPIRE. Der Inhalt soll die Kommentierung des En…“)
 
(Diese Seite wurde zum Übersetzen freigegeben)
Zeile 1: Zeile 1:
 
<translate>
 
<translate>
   
  +
<!--T:1-->
 
Diese Seiten befinden sich im Aufbau.
 
Diese Seiten befinden sich im Aufbau.
   
  +
<!--T:2-->
 
Ziel ist ein Überblick über UML vor dem Hintergrund von INSPIRE. Der Inhalt soll die Kommentierung des Entwurfs der Durchführungsbestimmungen "Data Specification" unterstützen. Zielgruppe sind die Beteiligten der GDI-RP.
 
Ziel ist ein Überblick über UML vor dem Hintergrund von INSPIRE. Der Inhalt soll die Kommentierung des Entwurfs der Durchführungsbestimmungen "Data Specification" unterstützen. Zielgruppe sind die Beteiligten der GDI-RP.
   
== Vorbemerkungen ==
+
== Vorbemerkungen == <!--T:3-->
   
  +
<!--T:4-->
 
INSPIRE - Infrastructure for Spatial Information in Europe
 
INSPIRE - Infrastructure for Spatial Information in Europe
   
  +
<!--T:5-->
 
Aufgabe: Datenspezifikationen des Annex I von INSPIRE sind zu kommentieren.
 
Aufgabe: Datenspezifikationen des Annex I von INSPIRE sind zu kommentieren.
 
Sie umfassen sog. Themen wie z.B. Cadastral Parcels.
 
Sie umfassen sog. Themen wie z.B. Cadastral Parcels.
Zeile 14: Zeile 18:
 
INSPIRE umfasst u.a. ein objektorientiertes Datenmodell.
 
INSPIRE umfasst u.a. ein objektorientiertes Datenmodell.
   
== Die Unified Modeling Language (UML) ==
+
== Die Unified Modeling Language (UML) == <!--T:6-->
   
  +
<!--T:7-->
 
INSPIRE bezieht sich auf UML. Dieser Text bezieht sich auf UML 1.4.2.
 
INSPIRE bezieht sich auf UML. Dieser Text bezieht sich auf UML 1.4.2.
 
UML ist eine Datenmodellierungssprache (www.omg.org) und ist unabhängig von Programmiersprachen. Der Dateninhalt und -struktur eindeutig formal beschreiben.
 
UML ist eine Datenmodellierungssprache (www.omg.org) und ist unabhängig von Programmiersprachen. Der Dateninhalt und -struktur eindeutig formal beschreiben.
   
== Objektorientierung ==
+
== Objektorientierung == <!--T:8-->
   
  +
<!--T:9-->
 
# UML ist geeignet, objektorientierte Datenmodelle zu beschreiben.
 
# UML ist geeignet, objektorientierte Datenmodelle zu beschreiben.
 
# UML stellt versch. Möglichkeiten für die Modellierung von Daten/Prozessen bereit: Klassendiagramme, Activity-Diagramme, Statechart-Diagramme, Interaction-Diagramme, usw.
 
# UML stellt versch. Möglichkeiten für die Modellierung von Daten/Prozessen bereit: Klassendiagramme, Activity-Diagramme, Statechart-Diagramme, Interaction-Diagramme, usw.
 
Für INSPIRE werden im Rahmen dieses Textes Klassendiagramme beleuchtet.
 
Für INSPIRE werden im Rahmen dieses Textes Klassendiagramme beleuchtet.
   
  +
<!--T:10-->
 
Zentraler Begriff: Objekt > Abstraktion der Realität
 
Zentraler Begriff: Objekt > Abstraktion der Realität
 
Software als Sammlung von Objekten
 
Software als Sammlung von Objekten
   
  +
<!--T:11-->
 
Objekt als Ansammlung von zusammengehörigen Informationen
 
Objekt als Ansammlung von zusammengehörigen Informationen
 
# Selbstbezogene Eigenschaften: Attribute
 
# Selbstbezogene Eigenschaften: Attribute
Zeile 34: Zeile 42:
 
# Funktionalität
 
# Funktionalität
   
== Objektorientierung / Begriff "Klasse" ==
+
== Objektorientierung / Begriff "Klasse" == <!--T:12-->
 
Klassen von Objekten: Beispiel: ''ProtectedArea'' als abstrakter Stellvertreter aller geschützten Gebiete.
 
Klassen von Objekten: Beispiel: ''ProtectedArea'' als abstrakter Stellvertreter aller geschützten Gebiete.
   
  +
<!--T:13-->
 
Klasse
 
Klasse
 
# Begriff der objektorientierten Modellierung
 
# Begriff der objektorientierten Modellierung
Zeile 42: Zeile 51:
 
# dient dazu, Objekte zu abstrahieren
 
# dient dazu, Objekte zu abstrahieren
   
== Objektorientierung / Begriff "Klasse" - "Instanz"==
+
== Objektorientierung / Begriff "Klasse" - "Instanz"== <!--T:14-->
 
Aus Klassen von Objekten kann man Instanzen von Objekten bilden.
 
Aus Klassen von Objekten kann man Instanzen von Objekten bilden.
 
Instanz = Ein konkreter Vertreter in der „Daten-Realität“.
 
Instanz = Ein konkreter Vertreter in der „Daten-Realität“.
 
Beispiel zu „Instanz“ der Klasse ''ProtectedArea'': Ein konkretes, reales geschütztes Gebiet im Datenbestand wie das Naturschutzgebiet „Rohr- und Gänswiesen“.
 
Beispiel zu „Instanz“ der Klasse ''ProtectedArea'': Ein konkretes, reales geschütztes Gebiet im Datenbestand wie das Naturschutzgebiet „Rohr- und Gänswiesen“.
   
== Klassendiagramm==
+
== Klassendiagramm== <!--T:15-->
 
Ein Klassendiagramm ist eine graphische Darstellung
 
Ein Klassendiagramm ist eine graphische Darstellung
 
# von Klassen sowie
 
# von Klassen sowie
 
# der Beziehungen zwischen diesen Klassen.
 
# der Beziehungen zwischen diesen Klassen.
   
  +
<!--T:16-->
 
Ein Klassendiagramm stellt eine / mehrere Klassen in unterschiedlichem Detaillierungsgrad und Kontext dar.Kontext kann hierbei z.B. die Klasse mit zugehörigen Datentypen u. Wertebereichen (Enumerationen) sein, aber auch die Verbindung zu anderen Klassen.
 
Ein Klassendiagramm stellt eine / mehrere Klassen in unterschiedlichem Detaillierungsgrad und Kontext dar.Kontext kann hierbei z.B. die Klasse mit zugehörigen Datentypen u. Wertebereichen (Enumerationen) sein, aber auch die Verbindung zu anderen Klassen.
   
  +
<!--T:17-->
 
Je nach Art des Kontextes reicht ggf. eine Darstellung ohne jegliche Details, z.B. um lediglich das Vorhandensein der Klasse im Verhältnis zu anderen Klassen zum Ausdruck zu bringen.INSPIRE spricht hierbei von ''„UML class diagram: Overview of the xyz application schema“''
 
Je nach Art des Kontextes reicht ggf. eine Darstellung ohne jegliche Details, z.B. um lediglich das Vorhandensein der Klasse im Verhältnis zu anderen Klassen zum Ausdruck zu bringen.INSPIRE spricht hierbei von ''„UML class diagram: Overview of the xyz application schema“''
 
Man sieht bei Klassendiagrammen also nicht immer zwangsläufig alle vorhandenen Informationen!
 
Man sieht bei Klassendiagrammen also nicht immer zwangsläufig alle vorhandenen Informationen!
   
== UML / Stereotyp ==
+
== UML / Stereotyp == <!--T:18-->
 
# Stereotyp = Art des Modellierungselements
 
# Stereotyp = Art des Modellierungselements
 
# Notation: <<Name des Stereotyps>>
 
# Notation: <<Name des Stereotyps>>
 
Stereotypen von INSPIRE: Vgl. INSPIRE DataSpecifiation-D2.5., „Recommendation 6: It is recommended that the use of UML conforms with ISO 19136 E.2.1.1.1-E.2.1.1.4.
 
Stereotypen von INSPIRE: Vgl. INSPIRE DataSpecifiation-D2.5., „Recommendation 6: It is recommended that the use of UML conforms with ISO 19136 E.2.1.1.1-E.2.1.1.4.
   
  +
<!--T:19-->
 
# ISO 19109 = Rules for applications schemas
 
# ISO 19109 = Rules for applications schemas
 
# Generic Conceptual Model = Grundlegendes Modellkonzept
 
# Generic Conceptual Model = Grundlegendes Modellkonzept
 
# Interessant: featureType beschränkt auf räumliche Obj.
 
# Interessant: featureType beschränkt auf räumliche Obj.
   
  +
<!--T:20-->
 
'''Type''' = Abstraktes konzeptuelles Element, d.h. es gibt keine Instanzen! Wird im Sinne der Vererbung genutzt: Allgemeine Eigenschaften auf abstrakter Ebene einmal definieren und auf Fachobjekt-Ebene n-mal nutzen. Beispiel:
 
'''Type''' = Abstraktes konzeptuelles Element, d.h. es gibt keine Instanzen! Wird im Sinne der Vererbung genutzt: Allgemeine Eigenschaften auf abstrakter Ebene einmal definieren und auf Fachobjekt-Ebene n-mal nutzen. Beispiel:
 
# <<Type>> Fahrzeug = Abstrakte Ebene / allg. Eigenschaft: Höchstgeschwindigkeit
 
# <<Type>> Fahrzeug = Abstrakte Ebene / allg. Eigenschaft: Höchstgeschwindigkeit
Zeile 71: Zeile 84:
   
   
== UML / Stereotype voidable ==
+
== UML / Stereotype voidable == <!--T:21-->
 
Anwendbar auf Attribute, Assoziationen (Relationen) und Rollen. Drückt aus, daß o.g. Eigenschaft in der Wirklichkeit, nicht jedoch im Datenbestand vorkommt. Hierzu gibt es sog. VoidableValueReason/Begründungen
 
Anwendbar auf Attribute, Assoziationen (Relationen) und Rollen. Drückt aus, daß o.g. Eigenschaft in der Wirklichkeit, nicht jedoch im Datenbestand vorkommt. Hierzu gibt es sog. VoidableValueReason/Begründungen
 
# „unknown“ = Im vorliegenden Einzelfall unbekannt
 
# „unknown“ = Im vorliegenden Einzelfall unbekannt
 
# „unpopulated“ = Generell für alle gleichartigen Fälle unbekannt
 
# „unpopulated“ = Generell für alle gleichartigen Fälle unbekannt
   
== UML / Stereotypen lifeCycleInfo und version ==
+
== UML / Stereotypen lifeCycleInfo und version == <!--T:22-->
 
Bemerkenswert:Stereotype „version“ ermöglicht versionsscharfe relationale Bezugnahme. Theoretisch auch in AAA möglich, bislang jedoch nicht praktisch.
 
Bemerkenswert:Stereotype „version“ ermöglicht versionsscharfe relationale Bezugnahme. Theoretisch auch in AAA möglich, bislang jedoch nicht praktisch.
   
== UML / Multiplizitäten / Kardinalitäten ==
+
== UML / Multiplizitäten / Kardinalitäten == <!--T:23-->
 
Häufigkeit des Auftretens einer Eigenschaft.
 
Häufigkeit des Auftretens einer Eigenschaft.
   
  +
<!--T:24-->
 
Notation: [Untergrenze .. Obergrenze]
 
Notation: [Untergrenze .. Obergrenze]
   
  +
<!--T:25-->
 
# Untergrenze und Obergrenze sind stets ganzzahlige positive Werte,
 
# Untergrenze und Obergrenze sind stets ganzzahlige positive Werte,
 
# Untergrenze kann Null sein.
 
# Untergrenze kann Null sein.
Zeile 90: Zeile 105:
 
# Keine Angabe entspricht exakt einmaligen Vorkommen.
 
# Keine Angabe entspricht exakt einmaligen Vorkommen.
   
== UML / Notation von Attributen ==
+
== UML / Notation von Attributen == <!--T:26-->
 
Vgl. 5.25.2 UML1.4.2-Spec.
 
Vgl. 5.25.2 UML1.4.2-Spec.
 
Sichtbarkeit Name : type-expression [ Multiplizität Sortierung ] = initial-value { property-string }
 
Sichtbarkeit Name : type-expression [ Multiplizität Sortierung ] = initial-value { property-string }
 
Beispiel aus INSPIRE:+ referencePoint: GM_Point [0..1]
 
Beispiel aus INSPIRE:+ referencePoint: GM_Point [0..1]
   
  +
<!--T:27-->
 
Sichtbarkeit von UML-Elementen
 
Sichtbarkeit von UML-Elementen
 
# <nowiki>+ =</nowiki> public, d.h. allgemein sichtbar
 
# <nowiki>+ =</nowiki> public, d.h. allgemein sichtbar
Zeile 101: Zeile 117:
 
Fehlende Sichtbarkeitsangaben = keine Aussage.
 
Fehlende Sichtbarkeitsangaben = keine Aussage.
   
  +
<!--T:28-->
 
# Type-expression = Sprachenabhängige Spezifizierung des Implementierungstyps eines Attributs. Z.B.: Integer, CharacterString, eigendefinierte Datentypen.
 
# Type-expression = Sprachenabhängige Spezifizierung des Implementierungstyps eines Attributs. Z.B.: Integer, CharacterString, eigendefinierte Datentypen.
 
# Initial value = Voreingestellter Wert, der bei Neuschaffung von Objekten Verwendung findet.
 
# Initial value = Voreingestellter Wert, der bei Neuschaffung von Objekten Verwendung findet.
 
# Property string = Ausdruck, der Eigenschaftswerte angibt, die auf das Element anwendbar sind. Z.B.: { frozen } bedeutet soviel wie „eingefroren“, nicht änderbar.
 
# Property string = Ausdruck, der Eigenschaftswerte angibt, die auf das Element anwendbar sind. Z.B.: { frozen } bedeutet soviel wie „eingefroren“, nicht änderbar.
   
== UML / Relationen ==
+
== UML / Relationen == <!--T:29-->
 
vgl. UML 1.4.2 Spec. 4.5.4.1
 
vgl. UML 1.4.2 Spec. 4.5.4.1
 
Oberbegriff zu: Assoziationen, Aggregationen, Kompositionen, Abhängigkeiten/Dependency, Generalisierung/Spezialisierung/Vererbung
 
Oberbegriff zu: Assoziationen, Aggregationen, Kompositionen, Abhängigkeiten/Dependency, Generalisierung/Spezialisierung/Vererbung
Zeile 116: Zeile 133:
 
# können sog. „Qualifier“ tragen UML
 
# können sog. „Qualifier“ tragen UML
   
== UML / Qualifier ==
+
== UML / Qualifier == <!--T:30-->
 
„Qualifier“ sind Attribute einer Assoziation. Sie wählen aus den Instanzen am anderen Ende der verbindenden Relation bestimmte aus.
 
„Qualifier“ sind Attribute einer Assoziation. Sie wählen aus den Instanzen am anderen Ende der verbindenden Relation bestimmte aus.
 
Vgl. UML 1.4.2 Spec. 5.4.5 u. 8.5.7. Beispiel:
 
Vgl. UML 1.4.2 Spec. 5.4.5 u. 8.5.7. Beispiel:
 
context Bank inv: self.customer
 
context Bank inv: self.customer
   
  +
<!--T:31-->
 
This results in a Set(Person) containing all customers of the Bank.
 
This results in a Set(Person) containing all customers of the Bank.
   
  +
<!--T:32-->
 
context Bank inv: self.customer[8764423]
 
context Bank inv: self.customer[8764423]
   
  +
<!--T:33-->
 
This results in one Person, having accountnumber 8764423.
 
This results in one Person, having accountnumber 8764423.
   
== UML / Relationstyp Aggregation ==
+
== UML / Relationstyp Aggregation == <!--T:34-->
 
Offener Diamant = Schwache Form der Beziehung „Einzelteile – Ganzes“, d.h. Einzelteile separat lebensfähig.
 
Offener Diamant = Schwache Form der Beziehung „Einzelteile – Ganzes“, d.h. Einzelteile separat lebensfähig.
   
== UML / Relationstyp Composition ==
+
== UML / Relationstyp Composition == <!--T:35-->
 
Gefüllter Diamant = Starke Form der Beziehung „Einzelteile – Ganzes“, d.h. Einzelteile separat NICHT lebensfähig.
 
Gefüllter Diamant = Starke Form der Beziehung „Einzelteile – Ganzes“, d.h. Einzelteile separat NICHT lebensfähig.
   
== UML / Relationstyp Generalisierung - Spezialisierung ==
+
== UML / Relationstyp Generalisierung - Spezialisierung == <!--T:36-->
 
# Vererbung von Eigenschaften von „Eltern“ auf „Kinder“ Generalisierung: Blickrichtung Kinder -> Eltern
 
# Vererbung von Eigenschaften von „Eltern“ auf „Kinder“ Generalisierung: Blickrichtung Kinder -> Eltern
 
# Spezialisierung: Blickrichtung Eltern -> Kinder
 
# Spezialisierung: Blickrichtung Eltern -> Kinder
 
# Auch mehrere Elternteile möglich!
 
# Auch mehrere Elternteile möglich!
   
== UML / Autorelation ==
+
== UML / Autorelation == <!--T:37-->
 
Scheinbar auf sich selbst verweisend, stehen in Wirklichkeit zwei verschiedene Instanzen dahinter.
 
Scheinbar auf sich selbst verweisend, stehen in Wirklichkeit zwei verschiedene Instanzen dahinter.
   
== UML / Relationen ==
+
== UML / Relationen == <!--T:38-->
 
Abhängigkeiten / Dependencies (Quelle: ISO 19136)
 
Abhängigkeiten / Dependencies (Quelle: ISO 19136)
   
== UML / Notes ==
+
== UML / Notes == <!--T:39-->
 
Notizen (Notes) dienen z.B. dem Unterbringen von OCL-Constraints.
 
Notizen (Notes) dienen z.B. dem Unterbringen von OCL-Constraints.
   
== UML / OCL-Constraints ==
+
== UML / OCL-Constraints == <!--T:40-->
 
OCL-Constraints sind in der Object Constraint Language verfasst. Sie drücken formalisiert Restriktionen und Zwänge aus.
 
OCL-Constraints sind in der Object Constraint Language verfasst. Sie drücken formalisiert Restriktionen und Zwänge aus.
 
</translate>
 
</translate>

Version vom 17. Mai 2019, 10:40 Uhr

<translate>

Diese Seiten befinden sich im Aufbau.

Ziel ist ein Überblick über UML vor dem Hintergrund von INSPIRE. Der Inhalt soll die Kommentierung des Entwurfs der Durchführungsbestimmungen "Data Specification" unterstützen. Zielgruppe sind die Beteiligten der GDI-RP.

Vorbemerkungen

INSPIRE - Infrastructure for Spatial Information in Europe

Aufgabe: Datenspezifikationen des Annex I von INSPIRE sind zu kommentieren. Sie umfassen sog. Themen wie z.B. Cadastral Parcels. Die Themen sind u.a. in der Unified Modeling Language UML beschrieben. INSPIRE umfasst u.a. ein objektorientiertes Datenmodell.

Die Unified Modeling Language (UML)

INSPIRE bezieht sich auf UML. Dieser Text bezieht sich auf UML 1.4.2. UML ist eine Datenmodellierungssprache (www.omg.org) und ist unabhängig von Programmiersprachen. Der Dateninhalt und -struktur eindeutig formal beschreiben.

Objektorientierung

  1. UML ist geeignet, objektorientierte Datenmodelle zu beschreiben.
  2. UML stellt versch. Möglichkeiten für die Modellierung von Daten/Prozessen bereit: Klassendiagramme, Activity-Diagramme, Statechart-Diagramme, Interaction-Diagramme, usw.

Für INSPIRE werden im Rahmen dieses Textes Klassendiagramme beleuchtet.

Zentraler Begriff: Objekt > Abstraktion der Realität Software als Sammlung von Objekten

Objekt als Ansammlung von zusammengehörigen Informationen

  1. Selbstbezogene Eigenschaften: Attribute
  2. Fremdbezogene Eigenschaften: Relationen
  3. Einschränkungen / Bedingungen: Constraints
  4. Funktionalität

Objektorientierung / Begriff "Klasse"

Klassen von Objekten: Beispiel: ProtectedArea als abstrakter Stellvertreter aller geschützten Gebiete.

Klasse

  1. Begriff der objektorientierten Modellierung
  2. beschreibt eine Menge von Objekten mit gleichen Eigenschaften
  3. dient dazu, Objekte zu abstrahieren

Objektorientierung / Begriff "Klasse" - "Instanz"

Aus Klassen von Objekten kann man Instanzen von Objekten bilden. Instanz = Ein konkreter Vertreter in der „Daten-Realität“. Beispiel zu „Instanz“ der Klasse ProtectedArea: Ein konkretes, reales geschütztes Gebiet im Datenbestand wie das Naturschutzgebiet „Rohr- und Gänswiesen“.

Klassendiagramm

Ein Klassendiagramm ist eine graphische Darstellung

  1. von Klassen sowie
  2. der Beziehungen zwischen diesen Klassen.

Ein Klassendiagramm stellt eine / mehrere Klassen in unterschiedlichem Detaillierungsgrad und Kontext dar.Kontext kann hierbei z.B. die Klasse mit zugehörigen Datentypen u. Wertebereichen (Enumerationen) sein, aber auch die Verbindung zu anderen Klassen.

Je nach Art des Kontextes reicht ggf. eine Darstellung ohne jegliche Details, z.B. um lediglich das Vorhandensein der Klasse im Verhältnis zu anderen Klassen zum Ausdruck zu bringen.INSPIRE spricht hierbei von „UML class diagram: Overview of the xyz application schema“ Man sieht bei Klassendiagrammen also nicht immer zwangsläufig alle vorhandenen Informationen!

UML / Stereotyp

  1. Stereotyp = Art des Modellierungselements
  2. Notation: <<Name des Stereotyps>>

Stereotypen von INSPIRE: Vgl. INSPIRE DataSpecifiation-D2.5., „Recommendation 6: It is recommended that the use of UML conforms with ISO 19136 E.2.1.1.1-E.2.1.1.4.

  1. ISO 19109 = Rules for applications schemas
  2. Generic Conceptual Model = Grundlegendes Modellkonzept
  3. Interessant: featureType beschränkt auf räumliche Obj.

Type = Abstraktes konzeptuelles Element, d.h. es gibt keine Instanzen! Wird im Sinne der Vererbung genutzt: Allgemeine Eigenschaften auf abstrakter Ebene einmal definieren und auf Fachobjekt-Ebene n-mal nutzen. Beispiel:

  1. <<Type>> Fahrzeug = Abstrakte Ebene / allg. Eigenschaft: Höchstgeschwindigkeit
  2. <<featureType>> Schiff = Fachobjekt-Ebene / spezielle Eigenschaft: Tiefgang und geerbt allg. Eigenschaft Höchstgeschwindigkeit


UML / Stereotype voidable

Anwendbar auf Attribute, Assoziationen (Relationen) und Rollen. Drückt aus, daß o.g. Eigenschaft in der Wirklichkeit, nicht jedoch im Datenbestand vorkommt. Hierzu gibt es sog. VoidableValueReason/Begründungen

  1. „unknown“ = Im vorliegenden Einzelfall unbekannt
  2. „unpopulated“ = Generell für alle gleichartigen Fälle unbekannt

UML / Stereotypen lifeCycleInfo und version

Bemerkenswert:Stereotype „version“ ermöglicht versionsscharfe relationale Bezugnahme. Theoretisch auch in AAA möglich, bislang jedoch nicht praktisch.

UML / Multiplizitäten / Kardinalitäten

Häufigkeit des Auftretens einer Eigenschaft.

Notation: [Untergrenze .. Obergrenze]

  1. Untergrenze und Obergrenze sind stets ganzzahlige positive Werte,
  2. Untergrenze kann Null sein.
  3. Obergrenze kann unbegrenzt sein („n“ oder „*“).
  4. Untergrenze ist stets kleiner als Obergrenze.
  5. Keine Angabe entspricht exakt einmaligen Vorkommen.

UML / Notation von Attributen

Vgl. 5.25.2 UML1.4.2-Spec. Sichtbarkeit Name : type-expression [ Multiplizität Sortierung ] = initial-value { property-string } Beispiel aus INSPIRE:+ referencePoint: GM_Point [0..1]

Sichtbarkeit von UML-Elementen

  1. + = public, d.h. allgemein sichtbar
  2. # = protected, d.h. nur Erben sichtbar
  3. - = private, d.h. steht nur sich selbst zur Verfügung.

Fehlende Sichtbarkeitsangaben = keine Aussage.

  1. Type-expression = Sprachenabhängige Spezifizierung des Implementierungstyps eines Attributs. Z.B.: Integer, CharacterString, eigendefinierte Datentypen.
  2. Initial value = Voreingestellter Wert, der bei Neuschaffung von Objekten Verwendung findet.
  3. Property string = Ausdruck, der Eigenschaftswerte angibt, die auf das Element anwendbar sind. Z.B.: { frozen } bedeutet soviel wie „eingefroren“, nicht änderbar.

UML / Relationen

vgl. UML 1.4.2 Spec. 4.5.4.1 Oberbegriff zu: Assoziationen, Aggregationen, Kompositionen, Abhängigkeiten/Dependency, Generalisierung/Spezialisierung/Vererbung

  1. stellen Verbindungen zwischen Klassen her
  2. können benannt sein
  3. gerichtet / navigierbar sein (Pfeilspitze)
  4. haben ggf. benannte Assoziationsenden („Rollen“)
  5. tragen ggf. Multiplizitäten
  6. können geordnet sein ( „{ordered}“ )
  7. können sog. „Qualifier“ tragen UML

UML / Qualifier

„Qualifier“ sind Attribute einer Assoziation. Sie wählen aus den Instanzen am anderen Ende der verbindenden Relation bestimmte aus. Vgl. UML 1.4.2 Spec. 5.4.5 u. 8.5.7. Beispiel: context Bank inv: self.customer

This results in a Set(Person) containing all customers of the Bank.

context Bank inv: self.customer[8764423]

This results in one Person, having accountnumber 8764423.

UML / Relationstyp Aggregation

Offener Diamant = Schwache Form der Beziehung „Einzelteile – Ganzes“, d.h. Einzelteile separat lebensfähig.

UML / Relationstyp Composition

Gefüllter Diamant = Starke Form der Beziehung „Einzelteile – Ganzes“, d.h. Einzelteile separat NICHT lebensfähig.

UML / Relationstyp Generalisierung - Spezialisierung

  1. Vererbung von Eigenschaften von „Eltern“ auf „Kinder“ Generalisierung: Blickrichtung Kinder -> Eltern
  2. Spezialisierung: Blickrichtung Eltern -> Kinder
  3. Auch mehrere Elternteile möglich!

UML / Autorelation

Scheinbar auf sich selbst verweisend, stehen in Wirklichkeit zwei verschiedene Instanzen dahinter.

UML / Relationen

Abhängigkeiten / Dependencies (Quelle: ISO 19136)

UML / Notes

Notizen (Notes) dienen z.B. dem Unterbringen von OCL-Constraints.

UML / OCL-Constraints

OCL-Constraints sind in der Object Constraint Language verfasst. Sie drücken formalisiert Restriktionen und Zwänge aus. </translate>