Quelltext der Seite UML/de


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
# <nowiki>+ =</nowiki> public, d.h. allgemein sichtbar
# <nowiki># =</nowiki> protected, d.h. nur Erben sichtbar
# <nowiki>- =</nowiki> 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.