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.
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.
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.
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
Klassen von Objekten: Beispiel: ProtectedArea als abstrakter Stellvertreter aller geschützten Gebiete.
Klasse
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“.
Ein Klassendiagramm ist eine graphische Darstellung
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!
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.
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:
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
Bemerkenswert:Stereotype „version“ ermöglicht versionsscharfe relationale Bezugnahme. Theoretisch auch in AAA möglich, bislang jedoch nicht praktisch.
Häufigkeit des Auftretens einer Eigenschaft.
Notation: [Untergrenze .. Obergrenze]
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
Fehlende Sichtbarkeitsangaben = keine Aussage.
vgl. UML 1.4.2 Spec. 4.5.4.1 Oberbegriff zu: Assoziationen, Aggregationen, Kompositionen, Abhängigkeiten/Dependency, Generalisierung/Spezialisierung/Vererbung
„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.
Offener Diamant = Schwache Form der Beziehung „Einzelteile – Ganzes“, d.h. Einzelteile separat lebensfähig.
Gefüllter Diamant = Starke Form der Beziehung „Einzelteile – Ganzes“, d.h. Einzelteile separat NICHT lebensfähig.
Scheinbar auf sich selbst verweisend, stehen in Wirklichkeit zwei verschiedene Instanzen dahinter.
Abhängigkeiten / Dependencies (Quelle: ISO 19136)
Notizen (Notes) dienen z.B. dem Unterbringen von OCL-Constraints.
OCL-Constraints sind in der Object Constraint Language verfasst. Sie drücken formalisiert Restriktionen und Zwänge aus.