Datenmodellierung Entity-Relationship-Modell (ER) … · Datenmodellierung-Entity-Relationship-Modell (ER) Unified Modeling Language (UML) Prof. Dr.-Ing. Ralf Bill Universität Rostock

Datenmodellierung-

Entity-Relationship-Modell (ER)Unified Modeling Language (UML)

Prof. Dr.-Ing. Ralf BillUniversität Rostock

Agrar- und Umweltwissenschaftliche FakultätProfessur für Geodäsie und Geoinformatik

GI-ER-UML © 2016 UNIVERSITÄT ROSTOCK | Geodäsie und Geoinformatik | Prof. Dr.-Ing. Ralf Bill

Anliegen

Klärung warum Modellierung entscheidend ist, nicht nur in der Geoinformatik

Klärung der wesentlichen Konzepte des Entitäten-Relationen-Modells (ER)

Klärung der wesentlichen Diagramme der Unified Modeling Language (UML)

Aufzeigen der Anwendung der UML im Normungskontext

GI-ER-UML © 2016 UNIVERSITÄT ROSTOCK | Geodäsie und Geoinformatik | Prof. Dr.-Ing. Ralf Bill 2

© 2016 UNIVERSITÄT ROSTOCK | Geodäsie und Geoinformatik | Prof. Dr.-Ing. Ralf Bill

Inhalt

Warum Modellierung?

Entitäten-Relationen-Modell (ER)

Unified Modeling Language (UML)

Fazit

GI-ER-UML 3

WARUM MODELLIERUNG?


Warum wollen/sollen wir modellieren?

Um komplexe Systeme (besser) zu verstehen, müssen sie abstrahiert werden Ein Modell ist eine Vereinfachung der Realität Wir können ein gesamtes komplexes System nicht in dessen Gesamtheit

verstehen Durch eine Modellierung werden vier Ziele erreicht:

1. Modelle helfen uns, ein System, wie es ist oder werden soll, zu visualisieren

2. Modelle erlauben es, die Struktur oder das Verhalten eines Systems zu spezifizieren

3. Modelle stellen eine Vorlage als Leitfaden während der Implementierung eines Systems dar

4. Modelle dokumentieren unsere Entscheidungen

Quelle: Booch, Rumbaugh & Jacobson, 1999GI-ER-UML © 2016 UNIVERSITÄT ROSTOCK | Geodäsie und Geoinformatik | Prof. Dr.-Ing. Ralf Bill 5

Die vier Prinzipien der Modellierung

1. Die Wahl des Modells beeinflusst, wie man ein Problem in Angriff nimmt und wie eine Lösung gestaltet wird. „The choice of what models to create has a profound influence on how a problem is

attacked and how a solution is shaped.“2. Jedes Modell darf mit unterschiedlichen Genauigkeiten ausgedrückt werden.

„Every model may be expressed at different levels of precision.“3. Die besten Modelle zeigen einen guten Bezug zur Realität.

„The best models are connected to reality.“4. Kein einzelnes Modell ist ausreichend. Jedes nicht-triviale System ist am besten

mittels einer kleinen Menge fast-unabhängiger Modelle angenähert. „No single model is sufficient. Every nontrivial system is best approached through a

small set of nearly independent models.“

Quelle: Booch, Rumbaugh & Jacobson, 1999


Objektorientierte Modellierung

Das Grundprinzip der objekt-orientierten Modellierung ist es, dass alle Entitäten als Objekte modelliert werden.

Die Eigenschaften eines Objektes werden als Attribute bzw. Attributwerte modelliert. Die Summe der Attributwerte eines Objektes definiert seinen Zustand.

Das Verhalten eines Objektes wird mittels Methoden abgebildet. Die Summe aller Methoden eines Objektes definiert seine Schnittstelle.

Jedes Objekt ist eine Instanz einer Klasse. Klassen gruppieren ähnliche Objekte und definieren deren Attribute und

Methoden. Ein Objekt kann Beziehungen zu anderen Objekten haben.


Objektorientiertes Datenmodell

Statische Eigenschaften Entitäten oder Objekte und ihre Eigenschaften (Merkmale/Attribute) Beziehungen zwischen den Objekten (Relationships)

Dynamische Eigenschaften Operationen Beziehungen zwischen Operationen

Integritätsbedingungen für Objekte Operationen

© 2016 UNIVERSITÄT ROSTOCK | Geodäsie und Geoinformatik | Prof. Dr.-Ing. Ralf BillGI-ER-UML 8

Beispiel einer objekt-orientierten Modellierung

Objekt 1: Klasse: Mensch Attribute / Attributwerte:

- Nachname: Nash- Vorname: Edward- Geschlecht: männlich- Große: 1,95m- Augenfarbe: blau

Methoden:- ansprechen

Beziehung 1: Zwischen: Objekt 1

Objekt 2 Vorwärts Beziehung: besitzt Rückwarts Beziehung: Besitzer

Objekt 2: Klasse: Auto Attribute / Attributwerte:

- Hersteller: Renault- Modell: Clio- Baujahr: 1992- Farbe: rot- Hubraum: 1197cm³

Methoden:- fahren- schieben


Warum eine standardisierte Modellierungssprache?

Normalerweise sind mehrere Personen in einem Modellierungsverfahren beteiligt. Öfter haben sie unterschiedliche Hintergrunde und Ansichten. Um eine effektive Kommunikation zu erlauben, wird eine gemeinsame Sprache benötigt.

Um Ergebnisse zu publizieren, wird ein breit verstandenes Format benötigt. Um Kompatibilität zwischen Werkzeuge zu ermöglichen, wird ein Standard benötigt.

Eine standardisierte Modellierungssprache ermöglicht es, sich auf das tatsächliche Problem zu konzentrieren.


ENTITY-RELATIONSHIPMODELING


Entity-Relationship-ModellERM (Chen 1976)

Das ER-Model analysiert die Beziehungen unterschiedlicher Typen von Entitäten/ Objekten in der realen Welt und beschreibt es für eine konzeptionelle Sicht.

Basiskonstrukte des ER-Modells: Entitäten (Features/Objekte)

- Objekte der realen Welt (oder ihre Abstraktion), über die Informationen gespeichert werden sollen, z.B. Haus, Straße, Baum

Im Modell als Rechteck dargestellt- Werden in strukturierter Form (z.B. tabellarisch) gespeichert

Entitätstypen (Feature class/Feature Type/Objektklasse)- Satz aller Entitäten mit gleichen Eigenschaften

– z.B. Personen, Häuser, Straßen, Bäume

Relationships/Beziehungen- Beziehungen zwischen Entitäten oder Entitätstypen

– z.B. gehört zu, hat Besitzer, hat, ist

- Beziehungen werden ebenfalls als Relation (Tabelle) behandelt- Im Modell als Raute dargestellt

Haus

hat Besitzer


Person

1:n

1:n

Entity-Relationship-ModellERM (Chen 1976)

Kardinalitäten – Beziehungstypen- Mengenangaben, mit denen in der Datenmodellierung für ER-Diagramme für jeden

Beziehungstyp festgelegt wird, wie viele Entitäten eines Entitätstyps mit genau einer Entität des anderen am Beziehungstyp beteiligten Entitätstyps (und umgekehrt) in Beziehung stehen können oder müssen. => 1:1, 1:n, n:m

Attribute- Eigenschaften, gemeinsam für alle {Entitäten|Beziehungen} derselben

{Entitäts-|Beziehungs}-Typen, z.B. beim Haus die Hausnummer, Stockwerkszahl usw. - Werden als Attributes (Spalten) in Tabellen abgelegt- Werden als Ellipse dargestellt- Schlüsselattribute der Entitäten und Attribute, die zu Beziehungen gehören,

werden als Attribute der Beziehungen und Fremdschlüssel abgelegt

Haus

Haus-nummer


Flächengröße

Stock-werks-zahl

Kardinalitäten/Relationships

1:1-Relationship Jede Entität eines Entitätstyps A kann exakt auf

eine Entität eines anderen Entitätstyps B abgebildet werden und umgekehrt

- z.B. Person-Mitarbeiter (Jede Person kann nur ein Mitarbeiter sein und umgekehrt [wie sieht es mit mehreren Arbeitsverträgen aus?)])

1:n-Relationship Jede Entität eines Entitätstyps A kann zu

mehreren Entitäten eines oder mehrere anderer Entitätstypen B abgebildet werden. Jedoch ist die Entität der anderen Entitätstypen nur exakt zu einer Entität des ersten Entitätstypen zugeordnet.e.

n:m-Relationship Jede Entität eines Entitätstyps A kann zu

mehreren Entitäten anderer Entitätstypen B abgebildet werden und umgekehrt

(m:n) - Relationship

Typ A Typ B

(1:1) - Relationship

Haus - ParzelleTrigonom. Punkt – Punktnummer

Haus - Stockwerke

Parzelle - Eigentümer

(1:n) - Relationship

125 127

126 128

TP12

HausEigentümerAdresse....

ParzelleEigentümerNummer....

Trigonome-tr. PunktNummer...


Schlüssel und Beziehungstypen

Schlüssel Attribut, welches zur eindeutigen Identifizierung einer Entity von einem Entity-Typ dient

- z.B. Personalausweisnummer, Mitarbeiternummer darf nur einmal für einen {Entität|Beziehung}-Typ vorkommen

Primärschlüssel Bei Vorkommen mehrerer Schlüssel wird einer als Primärschlüssel festgelegt.

Fremdschlüssel Attribut einer {Entität|Beziehung}, welches ein Primärschlüssel einer

{Entität|Beziehung} einer anderen {Entität|Beziehungs}-Typ darstellt Schwache Entitätstypen

Entität, die durch die eigenen Attribute allein nicht identifiziert werden können, nur durch eine weitere Beziehung

Selbes gilt für ganze Entitätstypen Schwache Beziehungstypen

an denen ein schwacher Entitätstyp teilnimmt


Entitäten-Relationen-Modell und logische Datenmodelle

Entitäten - Beziehungen

Abbildbar i.d.R. auf alle logischen Datenmodelle


Katas-terkarte

Parzellen

Kanten

Knoten

1 : n

3 : n

2 : n

HierarchischesDatenmodell

Netzwerk-Datenmodell

RelationalesDatenmodell

ObjektorientiertesDatenmodell

Beziehungen in einer tabularen Sicht

Relationales Datenmodell in heute gängigen relationalen Datenbanken => Tabellen

(1 : 1) Relationship Ein Datensatz einer Tabelle A kann nur exakt zu einem Datensatz der anderen Tabelle B verbunden werden. Umgekehrt kann der Datensatz der Tabelle B auch nur exakt zu einem Datensatz der Tabelle A verbunden werden.

(1 : n) Relationship Ein Datensatz einer Tabelle A kann nur exakt zu einem Datensatz der anderen Tabelle B verbunden werden. Umgekehrt kann der Datensatz der Tabelle B zu mehreren Datensätzen der Tabelle A verbunden werden.

(m : n) Relationship Ein Datensatz einer Tabelle A kann zu mehreren Datensätzen der anderen Tabelle B verbunden werden. Umgekehrt kann ein Datensatz der Tabelle B ebenfalls zu mehreren Datensätzen der Tabelle A verbunden werden.

Eine weitere Tabelle C ist notwendig, die mit den Primärschlüsseln beider Tabellen A und B besetzt ist.

Die Kombination der Schlüssel von Tabelle A und B ist der Primärschlüssel von C und muss eindeutig sein, d.h. nur einmal pro Zeile vorkommen.


UNIFIED MODELING LANGUAGE UML


Die Unified Modeling Language (UML)

Die Unified Modeling Language (dt: „die einheitliche Modellierungssprache“) ist eine normierte offene objekt-orientierte Modellierungssprache aus dem Softwareentwick-lungsbereich.

Sie definiert ein Metamodell und eine graphische Notation für die Modellierung von: Funktionalität Strukturen Abläufen und Interaktionen

Die UML spezifiziert 9 bzw. 13 Diagrammarten. Jedes Diagramm bildet einen Aspekt des Gesamtmodells ab.

Das Metamodell definiert eine einheitliche Semantik, die für alle Diagrammarten gilt.


Die Geschichte der UML

Die UML ist eine Fusion mehrerer älteren Modellierungssprachen. Die Stärken der Vorgänger ergänzen einander. Unterschiedliche Semantiken sind vereinigt.

Die frühe Versionen der UML (bis v0.9.1) waren hauptsächlich in einem Unternehmen (Rational Software) entwickelt. Booch, Jacobson und Rumbaugh, „die drei Amigos“

UML wird jetzt (seit v1.1) in Rahmen eines internationalen Konsortiums entwickelt. OMG (Object Management Group)

- Gegründet 1989- > 400 Mitglieder aus der Wissenschaft, Wirtschaft (Softwareentwickler und Endbenutzer) und

Verwaltung

UML 1.4.2 wurde 2005 als ISO19501 verabschiedet. Die aktuelle Version ist UML 2.1.1.


Die Entwicklung der objekt-orientierten Modellierung

Quelle: Wikipedia / oose.de (Lizenz: GNU FDL)GI-ER-UML © 2016 UNIVERSITÄT ROSTOCK | Geodäsie und Geoinformatik | Prof. Dr.-Ing. Ralf Bill 21

Nebenspezifikationen zur UML

Eine standardisierte Sprache, um Bedingungen in einer Programmiersprache-unabhängigen Form zu spezifizieren, ist auch spezifiziert. Object Constraint Language (OCL)

Ein XML-basiertes Dateiformat für den Austausch von Modellen bzw. Diagrammen zwischen Software ist ebenso normiert. XML Metadata Interchange (XMI), auch ISO19503:2005


Kritik an der UML

Die Entwicklung und Verbreitung von UML ist nicht ohne Kritik gelaufen. Am häufigsten wird kritisiert:

Der Umfang der Sprache ist sehr groß geworden („language bloat“) Die Semantik ist nicht immer genau bzw. formal definiert Die Nutzung von UML kann einen negativen Einfluss auf die Form der

entwickelten Lösung haben UML wird zu oft eingesetzt, auch wenn es nicht die beste Lösung ist bzw. wenn

die benötigten Kenntnisse fehlen- „Death by UML Fever“


UML-Diagrammarten

9 Diagrammarten in UML 1 Klassendiagramm Class Diagram Zustandsdiagramm State Diagram Aktivitätsdiagramm Activity Diagram Anwendungsfalldiagramm Use-Case Diagram Sequenzdiagramm Sequence Diagram Kollaborationsdiagramm (UML 1) Collaboration Diagram

Kommunikationsdiagramm (UML 2) Communication Diagram Objektdiagramm Object Diagram Komponentendiagramm Component Diagram Verteilungsdiagramm Deployment Diagram

4 zusätzliche Diagrammarten in UML 2 Paketdiagramm Package Diagram Zeitverlaufsdiagramm Timing Diagram Kompositionsstrukturdiagramm Composite Structure Diagram Interaktionsübersichtsdiagramm Interaction Overview Diagram


UML-Klassendiagramm

Das Klassendiagramm zeigt die statische Struktur eines Systems Es ist das am häufigsten verwendete Diagramm für die objekt-orientierte

Modellierung Ein Klassendiagramm stellt dar:

Klassen und deren- Attribute- Methoden- Beziehungen

Schnittstellen Kollaborationen Generalisationen

Klassendiagramme werden während einer Systemanalyse, -entwurf oder –implementierung eingesetzt


Anwendungen Klassendiagramm

Um das Vokabular eines Systems zu modellieren Definition einer Ontologie bzw. Semantik Definition eines Objekt- bzw. Featurekatalogs

Um einfache Kollaborationen zu modellieren Um Klassen bzw. Komponenten und deren Beziehungen zu visualisieren Für die Umsetzung in einer objekt-orientierten Programmiersprache

Um ein logisches Datenbankschema zu modellieren Für relationale oder objekt-orientierte Datenbänke Für XML-Schema oder andere Ablage- bzw. Übertragungsformate

Quelle: nach Booch, Rumbaugh & Jacobson, 1999GI-ER-UML © 2016 UNIVERSITÄT ROSTOCK | Geodäsie und Geoinformatik | Prof. Dr.-Ing. Ralf Bill 26

Beziehung

0..1

Komposition

1..*

Aggregation

0..*

verallgemeinerte Klasse«Stereotyp»

+erstes Attribut:float +Beziehung:verwandte Klasse #zweites Attribut:char

+erste Methode(): void

spezialisierte Klasse

+Komposition:noch eine Klasse +Aggregation:andere Klasse -drittes Attribut:int

verwandte Klasse

+ein Attribut:bool

noch eine Klasse

+ein Attribut:double

andere Klasse

+ein Attribut:long

SyntaxKlassendiagramm

KlassennameAttribute

Methoden

Multiplizität

Komposition Aggregation

Beziehung

Generalisierung

verstecktes Attribut

geschütztes Attribut

öffentlichesAttribut

Stereotyp


BeispielKlassendiagramm

AX_Fortfuehrungsfall(from Fortführungsnachweis)

<<Feature>>

AX_Buchungsstelle(from Personen- und Bestandsdaten)

<<Feature>>

AX_LagebezeichnungOhneHausnummer(from Angaben zur Lage)

<<Feature>>AX_LagebezeichnungMitHausnummer

(from Angaben zur Lage)

<<Feature>>

AX_Flurstueck<<Feature>>

0..*

0..*

+beziehtSichAufFlurstueck

0..*

+gehoertAnteil igZu 0..*

1

0..*

+istGebucht 1

+grundstueckBestehtAus 0..*0..*

0..*

+verweistAuf0..*

0..*

0..*

1..*

+zeigtAuf0..*

+gehoertZu1..*

0..*

1..*

+weistAuf 0..*

+gehoertZu

1..*

AX_Vertretung(from Personen- und Bestandsdaten)

<<Feature>>0..* 0..*+beziehtSichAuf0..* 0..*

AX_BesondereFlurstuecksgrenze<<Feature>>

AX_Grenzpunkt<<Feature>>

0..*0..1 0..*+zeigtAuf0..1

Quelle: AAA Modell (AdV, 2006)GI-ER-UML © 2016 UNIVERSITÄT ROSTOCK | Geodäsie und Geoinformatik | Prof. Dr.-Ing. Ralf Bill 28

UML-Aktivitätsdiagramm

Ein Aktivitätsdiagramm bildet den logischen Ablauf eines Systems ab Vgl.: ein klassisches Flussdiagramm

Das Aktivitätsdiagramm eignet sich besonders für die Modellierung von Geschäftsprozessen und Vorgängen

Die einzelnen Arbeitsschritte des Gesamtprozesses sind als Aktivitäten dargestellt Wer die Aktivität durchführt, kann auch dargestellt werden

Die möglichen Reihenfolgen der Aktivitäten sind mit Pfeilen markiert


[Bedingung]

Klasse::Aktivität 1

Klasse::Aktivität 2 Klasse::Aktivität 3

Syntax Aktivitätsdiagramm

Aktivität

Entscheidung

Bedingung

Startzustand

Endzustand

Kontrollfluss

Synchronisation

Aktive Klasse Aktivitätsname


Beispiel Aktivitätsdiagramm

Eingabedatensatz abrufen

Rectify

Clip Normalisierung

Clustering

Vektorisierung

Mindestgroße-Filter

einmal proEingabe


UML-Zustandsdiagramm

Ein Zustandsdiagramm bildet eine Zustandsmaschine ab, mit dem Fokus auf die möglichen Zustände des Objektes bzw. der Objekten. Ein Aktivitätsdiagramm ist auf die Übergänge bzw. die verursachenden Aktivitäten

fokussiert. Ein Zustandsdiagramm spezifiziert das Verhalten eines Systems und wie es auf

Ereignisse (Übergangsfunktionen) reagiert.


Syntax Zustandsdiagramm

Übergang

AnfangszustandBedingung

Endzustand

Zustand


Beispiel Zustandsdiagramm

Quelle: nach Seemann, Wolff von Gudenberg, 2000GI-ER-UML © 2016 UNIVERSITÄT ROSTOCK | Geodäsie und Geoinformatik | Prof. Dr.-Ing. Ralf Bill 34

UML-Sequenzdiagramm

Das Sequenzdiagramm beschreibt den Ablauf der Kommunikation in einer Gruppe von Objekten.

Die Bestandteile des Sequenzdiagrammes sind: Objekte und deren Lebenslinien Nachrichten Aktivitätszonen

Das Sequenzdiagramm stellt den Fokus auf die zeitliche Reihenfolge der Nachrichten und welche Objekte zu einer bestimmten Zeit aktiv sind.

Das Sequenzdiagramm ermöglicht es, die Interaktionen zwischen Komponenten klar darzustellen.


Syntax Sequenzdiagramm

ObjektObjektname Klassenname

Lebenslinie

Aktives Objekt

Objekt erzeugen

Objekt zerstören

BedingungBotschaften


Beispiel Sequenzdiagramm


UML-Anwendungsfalldiagramm

Anwendungsfalldiagramme stellen die Anforderungen an ein System dar. Die erforderliche Funktionalität des Systems kann davon abgeleitet werden.

Anwendungsfalldiagramme zeigen: was ein System macht bzw. machen soll (Anwendungsfälle), wer mit dem System interagiert (Akteure) und was sie damit machen (Rollen).

Zusätzliche können Anwendungsfalldiagramme Beziehungen zwischen Anwendungsfällen und zwischen Akteuren abbilden.


Rolle

etwas andere Rolle

Rol

le «include»

allgemeiner Anwendungsfall

untergeordneter Anwendungsfall

spezialisierter Anwendungsfall

verallgemeinter Akteur

spezialisierter AkteurAkteur

Syntax Anwendungsfalldiagramm

Anwendungsfall AkteurGeneralisierung

Generalisierung

Rolle

Benutzt


Beispiel Anwendungsfalldiagramm

GDI-PF nutzen

Dienste bereitstellen

Dienste nutzen

Benutzer einer GDI-PF

Landwirt

Dienstleister

LohnunternehmerBehörde

Berater


UML-Kollaborationsdiagramm

Das Kollaborationsdiagramm ist mit dem Sequenzdiagramm semantisch vergleichbar. Das Sequenzdiagramm zeigt den zeitliche Ablauf der Kollaboration, das

Kollaborationsdiagramm den logischen Ablauf. Kollaborationsdiagramme sind für komplexe Iterationen und Verzweigung und für

parallele Verfahren besser geeignet.


UML-Objektdiagramm

Das Objektdiagramm modelliert Objekte und deren Beziehungen zu einem bestimmten Zeitpunkt.

Es ist praktisch eine Abbildung einer Instanz eines Klassendiagramms oder ein Schnappschuss eines Interaktionsdiagramms.

Die Klassen werden auch manchmal in dem Objektdiagramm gezeigt.


UML-Komponentendiagramm

Das Komponentendiagramm bildet die Struktur eines Systems während der Implementierungsphase ab.

Es zeigt Abhängigkeiten zwischen Komponenten in dem System und deren Schnittstellen.

Das Komponentendiagramm ist eine besondere Art Objekt- bzw. Klassendiagramm.

Anwendungen eines Komponentendiagrammes sind: um Software zu modellieren, um physische Datenbänke zu modellieren und um anpassungsfähige Systeme zu modellieren.

WebGIS-Client

WebGIS-Server WMS

Datenbank SQL-SF


UML-Verteilungsdiagramm

Das Verteilungsdiagramm zeigt die Konfiguration eines implementierten Systems. Das Verteilungsdiagramm kann als eine Art Objekt- oder Klassendiagramm

betrachtet werden. Der Fokus liegt auf dem Knoten des Systems.

Das Verteilungsdiagramm wird am häufigsten verwendet für die Modellierung von: eingebetteten Systemen, Client-Server Systemen und verteilten Systemen.


UML-Paketdiagramm (UML 2)

Das Paketdiagramm zeigt die Abhängigkeiten zwischen Paketen in einem System. Pakete erlauben eine Modularisierung des Systems, um große Systeme übersichtlicher

zu machen. Das Paketdiagramm kann als Übersicht eines Klassendiagramms dienen.


Nutzung der UML in ISO19100-Normen

Die UML wird häufig in der ISO19100-Normen verwendet. Sie dient als allgemeine graphische Notation für konzeptionelle und konkrete

Modelle. Ein Profil und Regeln für die Nutzung der UML in der ISO19100-Serie ist in ISO19103

definiert. Insbesondere wird das Klassendiagramm sehr oft benutzt, um Begriffe,

Zusammenhänge und Datentypen zu definieren. Definitionssprache für die Semantik bzw. Ontologie Definitionssprache für das ISO-Metamodell für Geodaten

Zusätzlich definiert ISO19136 („GML – Geography Markup Language“) Regeln für UML-GML und GML-UML-Kodierung. Basiert auf ISO19118 („Geographic Information – Encoding“) Man modelliert ein Anwendungsgebiet mit UML und implementiert ein Datenformat mit

XML bzw. GML. In den nächsten Folien werden einige Beispiele aus den ISO-Normen gezeigt.


High-level view of the Domain reference model

Quelle: ISO19101, Fig. 5GI-ER-UML © 2016 UNIVERSITÄT ROSTOCK | Geodäsie und Geoinformatik | Prof. Dr.-Ing. Ralf Bill 47

Details of the application schema


Examplepackage structure


Data types fortemporal position


Attributes offeature types


UML implementation of feature types


Translucentchaining


Softwarefür UML

Da UML ursprünglich für die Softwareentwicklung entwickelt wurde, gibt es natürlich eine Vielfalt von Software, um UML einzusetzen.

Der Fokus, Benutzerfreundlichkeit, Art und Umfang der Implementierung und unterstützte Versionen der UML sind jeweils sehr unterschiedlich. von einfacher Zeichnung bis hin zur „round-trip engineering“.

Freie, kostenlose und proprietäre Software für die UML sind erhältlich. XMI-Unterstützung ist in vielen Fällen immer noch problematisch.

Unterschiedliche XMI- und UML-Versionen fehlende Kompatibilität Viele Liste von UML-Software sind online zu finden.

http://www.oose.de/umltools.htm http://www.objectsbydesign.com/tools/umltools_byCompany.html


Proprietäre UML-Software

Rational Rose ist die „originale“ UML-Software, jetzt von IBM veröffentlicht. Viele andere UML-Werkzeuge bieten Kompatibilität mit Rose MDL-Dateien an.

- Allerdings gibt es viele unterschiedliche Versionen des MDL-Formats Rational Rose ist in vielen Versionen mit unterschiedlichem Fokus erhältlic.h

- Data Modeler, Technical Developer, Enterprise, … Rational Rose wird häufig für große Projekte eingesetzt (e.g. AAA). Unterstützung für XMI ist noch mangelhaft. Läuft unter Windows oder Linux.

Enterprise Architect ist ein Produkt der Firma Sparx Systems. Es unterstützt alle 13 Diagrammarten der UML 2. Fokus auf kollektive Arbeit (das Modell kann in einer Datenbank gespeichert werden). Unterstützung für XMI Import-Export. Läuft unter Windows oder Linux.

Microsoft Visio kann ebenfalls UML-Modelle erstellen.


Kostenlose UML-Software

Viele proprietäre UML-Software ist auch in einer kostenlosen Version erhältlich, normalerweise mit eingeschränkter Funktionalität oder Lizenzbedingung (z.B. nur für die nicht-kommerzielle Nutzung) Poseidon von GentleWare ist eine proprietäre Weiterentwicklung der freien argoUML,

mit einer kostenlosen „Community Version“- Kein Export

Omondo bietet eine kostenlose EclipseUML Eclipse IDE Plugin an- Mit Unterstützung für UML2 und XMI Export (Import nur in der kostenpflichtigen Version)

VisualParadigm hat ebenfalls eine kostenlose „Community Version“- Mit Unterstützung für UML2 und XMI- Wasserzeichen in allen ausgedrückten Diagramme


Freie UML-Software

Freie (Open-Source) UML-Software bieten oft eine gute Alternative zur proprietären Lösungen an. argoUML ist eine Java-basierte UML-Modellierungssoftware mit einigen interessanten

Funktionen.- „kognitive Psychologie“, „Design-Kritiken“ und Checklisten- Quellcodegeneration für verschiedene Programmiersprachen- Unterstützung für UML 1.3 und 1.4 und XMI 1.0, 1.1 und 1.2

Umbrello ist Teil des KDE-Desktops (läuft nur unter Linux).- Quellcodegeneration für viele Programmiersprachen bzw. DDL- Unterstützung für UML 1.5 und XMI 1.2

StarUML ist eine Windows-basierte Software.- Unterstützung für UML 2.0 und XMI 1.1

Dia, ein freies Zeichnungsprogramm, kann UML-Diagramme erstellen. OpenOffice Draw hat ebenfalls Werkzeuge für UML-Diagramme.


Fazit


Fazit

Ein Modell ist oft ein nützliches Werkzeug, um ein System besser zu verstehen bzw. zu spezifizieren.

Die UML ist eine weitestgehend akzeptierte normierte objekt-orientierte Modellierungssprache.

Die UML definiert ein Metamodell und 9 bzw. 13 Diagrammarten zur Darstellung verschiedener Aspekte eines Modells.

Sie kann in vielen Anwendungsbereichen eingesetzt. Sie eignet sich besonders für Daten- und Prozessmodellierung für die

Geoinformatik. Es existieren eine Vielfalt von Software, um UML-Modelle zu erstellen.

Ein UML-Modell kann als Basis einer automatisierten Implementierung dienen.

„All models are wrong, but some are useful“- George E. P. Box (Statistiker)


Selbststudium


Literatur-hinweis

GI-ER-UML © 2016 UNIVERSITÄT ROSTOCK | Geodäsie und Geoinformatik | Prof. Dr.-Ing. Ralf Bill

Bücher: Bill (2016): Kapitel 4, 6 Bartelme (2005): Kapitel 9.6 (UML) de Lange (2013): Kapitel 8.2 (ER)

Literatur: Booch, G., Rumbaugh, J., Jacobson, I. (1999): Das UML-Benutzerhandbuch. Addison-

Wesley. 592 Seiten.61

Documents

Datenmodellierung Entity-Relationship-Modell (ER) … · Datenmodellierung-Entity-Relationship-Modell (ER) Unified Modeling Language (UML) Prof. Dr.-Ing. Ralf Bill Universität Rostock