UML: Unterschied zwischen den Versionen
Felde (Diskussion | Beiträge) (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…“) |
Felde (Diskussion | Beiträge) (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
- 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.
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
- Selbstbezogene Eigenschaften: Attribute
- Fremdbezogene Eigenschaften: Relationen
- Einschränkungen / Bedingungen: Constraints
- Funktionalität
Objektorientierung / Begriff "Klasse"
Klassen von Objekten: Beispiel: ProtectedArea als abstrakter Stellvertreter aller geschützten Gebiete.
Klasse
- Begriff der objektorientierten Modellierung
- beschreibt eine Menge von Objekten mit gleichen Eigenschaften
- 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
- von Klassen sowie
- 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
- Stereotyp = Art des Modellierungselements
- 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.
- ISO 19109 = Rules for applications schemas
- Generic Conceptual Model = Grundlegendes Modellkonzept
- 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:
- <<Type>> Fahrzeug = Abstrakte Ebene / allg. Eigenschaft: Höchstgeschwindigkeit
- <<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
- „unknown“ = Im vorliegenden Einzelfall unbekannt
- „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]
- Untergrenze und Obergrenze sind stets ganzzahlige positive Werte,
- Untergrenze kann Null sein.
- Obergrenze kann unbegrenzt sein („n“ oder „*“).
- Untergrenze ist stets kleiner als Obergrenze.
- 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
- + = public, d.h. allgemein sichtbar
- # = protected, d.h. nur Erben sichtbar
- - = private, d.h. steht nur sich selbst zur Verfügung.
Fehlende Sichtbarkeitsangaben = keine Aussage.
- 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.
- 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
- stellen Verbindungen zwischen Klassen her
- können benannt sein
- gerichtet / navigierbar sein (Pfeilspitze)
- haben ggf. benannte Assoziationsenden („Rollen“)
- tragen ggf. Multiplizitäten
- können geordnet sein ( „{ordered}“ )
- 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
- Vererbung von Eigenschaften von „Eltern“ auf „Kinder“ Generalisierung: Blickrichtung Kinder -> Eltern
- Spezialisierung: Blickrichtung Eltern -> Kinder
- 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>