Was ist ein UML Diagramm?

Die Unified Modeling Language (UML) wurde entwickelt, um eine gemeinsame, semantisch und syntaktisch umfangreiche visuelle Modellierungssprache für die Architektur, das Design und die Implementierung von komplexen Softwaresystemen zu schaffen – und zwar sowohl für strukturelle als auch für verhaltensbasierte Modelle. Die UML wird weit über die Softwareentwicklung hinaus eingesetzt, so zum Beispiel für Abläufe von Herstellungsprozessen.

Die UML entspricht den Konzepten, die in anderen Bereichen verwendet werden, und besteht aus verschiedenen Diagrammarten. Insgesamt beschreiben UML-Diagramme die Grenzen, die Struktur und das Verhalten von Systemen und den darin enthaltenen Objekten.

UML ist keine Programmiersprache, aber es gibt Tools, die UML-Diagramme nutzen, um Code in verschiedenen Sprachen zu generieren. UML hat einen direkten Bezug zu objektorientierter Analyse und Design.

UML und seine Rolle beim objektorientierten Modellieren und Design

In der Informatik, also der Wissenschaft von Algorithmen und Daten, gibt es viele Paradigmen oder Modelle zur Lösung von Problemen. Dabei stehen vier Modellkategorien für die Problemlösung zur Verfügung: imperative, funktionale, deklarative und objektorientierte Sprachen (OOP). In objektorientierten Sprachen werden Algorithmen durch die Definition von „Objekten“ und die Interaktion der Objekte untereinander ausgedrückt. Diese Objekte können manipuliert werden und sie existieren in der echten Welt. Dabei kann es sich um Gebäude, Widgets auf einem Desktop oder Menschen handeln. Objektorientierte Sprachen dominieren die Welt der Programmierung, denn sie können reale Objekte modellieren. UML ist eine Kombination aus mehreren objektorientierten Notationen: objektorientiertes Design, Objektmodellierungstechnologie und objektorientierte Softwareentwicklung. UML nutzt die Stärken dieser drei Ansätze für ein schlüssigeres Verfahren, das sich einfacher verwenden lässt. UML vereint die Best Practices für die Erstellung und Dokumentation unterschiedlicher Aspekte der Modellierung von Software- und Geschäftssystemen.

Die Geschichte und Ursprünge von UML

Die „3 Amigos“ der Softwareentwicklung – so wurden sie in Fachkreisen genannt – hatten andere Methodiken weiterentwickelt. Sie arbeiteten gemeinsam an einer Lösung, um durch neue Standards Klarheit für Programmierer zu schaffen. Die Zusammenarbeit von Grady, Booch und Rumbaugh verbesserte alle drei Methoden und optimierte das finale Produkt. Durch den unermüdlichen Einsatz dieser Vordenker kam es 1996 zur Veröffentlichung der UML 0.9- und 0.91-Dokumente. Schnell war klar, dass UML in mehreren Organisationen – darunter Microsoft, Oracle und IBM – als entscheidend für die eigene Geschäftsentwicklung angesehen wurde. Gemeinsam mit vielen anderen Einzelpersonen und Unternehmen erarbeiteten sie Ressourcen, mit denen man eine vollwertige Modellierungssprache entwickeln konnte. Die 3 Amigos veröffentlichten 1999 einen Benutzerleitfaden für einheitliche Modellierungssprache („The Unified Modeling Language User Guide“) und 2005 folgte eine zweite überarbeitete Auflage mit Informationen über UML 2.0.

OMG: Nicht das, was Sie denken!

Laut ihrer Website ist die Object Management Group® (OMG®) ein internationales, nicht gewinnorientiertes Konsortium zur Förderung von Technologiestandards, das 1989 ins Leben gerufen wurde und auf einem Konzept der offenen Mitgliedschaft basiert. Die OMG-Standards werden von Anbietern, Endnutzern, Bildungseinrichtungen und Behörden festgelegt. OMG Task Forces entwickeln Integrationsstandards für Unternehmen für eine breite Palette an Technologien und eine noch breitere Palette an Branchen. Die Modellierungsstandards von OMG, darunter UML und Model Driven Architecture® (MDA®), machen es möglich, dass Software- und andere Prozesse aussagekräftig visuell dargestellt, ausgeführt und gewartet werden können. Die OMG überwacht die Definition und Einhaltung der UML-Spezifikationen. Dadurch können Entwickler und Programmierer zu unterschiedlichsten Zwecken in sämtlichen Phasen des Software-Lebenszyklus für Systeme aller Größen auf eine einheitliche Sprache zurückgreifen.

Der Zweck von UML

Die OMG definiert den Zweck der UML wie folgt: - Systemarchitekten und Softwareentwickler erhalten ein Tool für die Analyse, das Design und die Implementierung von softwarebasierten Systemen sowie für die Modellierung von Geschäfts- und ähnlichen Prozessen. - Die Branchensituation soll optimiert werden, indem dafür gesorgt wird, dass Tools zur visuellen Modellierung von Objekten miteinander kompatibel sind. Allerdings ist es für einen sinnvollen Austausch von Modelldaten zwischen Tools notwendig, dass eine einheitliche Notation und Semantik verwendet wird. UML erfüllt die folgenden Anforderungen: - Festlegung einer formalen Definition für ein gemeinsames Metamodell, das auf Meta-Object Facility (MOF) basiert und die abstrakte Syntax der UML spezifiziert. Die abstrakte Syntax definiert die UML-Modellierungskonzepte, ihre Attribute und ihre Beziehungen sowie die Regeln für die Kombination dieser Konzepte zur Entwicklung partieller oder kompletter UML-Modelle. - Eine detaillierte Erklärung der Semantik für jedes einzelne UML-Modellierungskonzept. Die Semantiken definieren – in einer von der Technologie unabhängigen Art und Weise –, wie die UML-Konzepte von Computern realisiert werden. - Bestimmung der von Menschen lesbaren Notationselemente für die Darstellung individueller UML-Modellierungskonzepte sowie die Festlegung von Regeln für die Kombination solcher Konzepte, um eine Vielzahl von Diagrammarten für verschiedene Aspekte des modellierten Systems erstellen zu können. - Festlegung von Methoden, mit denen gewährleistet werden kann, dass UML-Tools mit dieser Spezifizierung übereinstimmen. Dies wird (in einer separaten Spezifizierung) durch eine XML-basierte Spezifizierung von zugehörigen Modell-Austauschformaten (XMI) unterstützt – konforme Tools müssen diesen Prozess dann durchlaufen.

UML und Datenmodellierung

Die UML ist zwar unter Programmierern beliebt, wird aber in der Regel nicht von Datenbankentwicklern verwendet. Einer der Gründe dafür ist, dass die UML-Ersteller ihren Schwerpunkt nicht auf Datenbanken gelegt haben. Dennoch ist die UML für die allgemeine Darstellung von Datenmodellkonzepten geeignet und kann für verschiedene Arten von UML-Diagrammen eingesetzt werden. Für Informationen über die Verwendung von Schichten in einem objektorientierten Klassenmodell in einer relationalen Datenbank lesen Sie diesen Artikel über die Datenbankmodellierung in UML:

Neuerung bei UML 2.0

UML wird kontinuierlich verbessert. UML 2.0 ist eine erweiterte Variante von UML, mit der noch mehr Aspekte der Entwicklung abgedeckt werden können, so zum Beispiel agile Konzepte. Ziel war es, UML neu zu strukturieren und zu optimieren und somit die Benutzerfreundlichkeit, die Implementierung und die Anpassung zu vereinfachen. Hier sind einige der wichtigsten Neuerungen bezüglich UML-Diagrammen: - Bessere Integration zwischen strukturellen und verhaltensbasierten Modellen. - Möglichkeit, eine Hierarchie und eine Aufschlüsselung eines Softwaresystems in Komponenten und untergeordnete Komponenten abzubilden. - UML 2.0 erhöht die Anzahl an Diagrammen von 9 auf 13.

UML-Begriffsglossar

Machen Sie sich mit dem UML-Vokabular vertraut: In der folgenden Liste finden Sie ausgewählte Begriffe aus dem UML 2.4.1-Dokument, das Nichtmitgliedern der OMG dabei helfen soll, häufig verwendete Begriffe zu verstehen: - Einhaltung abstrakter Syntax Benutzer können Modelle von einem Tool auf ein anderes übertragen, selbst wenn sie unterschiedliche Notationen verwenden - Common Warehouse Metamodel (CWM) Standard-Schnittstellen, die für den Austausch von Warehouse- und Business-Intelligence-Metadaten zwischen Warehouse-Tools, Warehouse-Plattformen und Warehouse-Metadatenspeichern in verteilten heterogenen Umgebungen verwendet werden. - Einhaltung konkreter Syntax Benutzer können weiterhin in unterschiedlichen Tools die Notation verwenden, mit der sie vertraut sind - Kern Im Kontext von UML bezieht sich der Begriff „Kern“ in der Regel auf das „Kernpaket“, wobei es sich um ein vollständiges Metamodell handelt, das speziell für eine hohe Wiederverwendbarkeit entwickelt wurde - Spracheinheit Besteht aus einer Sammlung eng zusammenhängender Modellierungskonzepte, die Benutzern die Möglichkeit bieten, ausgewählte Aspekte des Systems nach einem bestimmten Paradigma oder Formalismus darzustellen - Ebene 0 (E0) Die unterste Compliance-Ebene in der UML-Infrastruktur – eine einzelne Spracheinheit, mit der die Modellierung von verschiedenen Arten von klassenbasierten Strukturen möglich ist, die in den meisten verwendeten objektorientierten Programmiersprachen auftreten - Meta Object Facility (MOF) Eine von der OMG eingeführte Modellierungsspezifikation, die die Grundlage für die Metamodelldefinitionen in der MDA-Sprachfamilie der OMG bildet - Metamodell Definiert die Sprache und die Prozesse, aus denen ein Modell entwickelt wird - Metamodell-Konstrukte (LM) Die zweite Compliance-Ebene in der UML-Infrastruktur – eine zusätzliche Spracheinheit für erweiterte klassenbasierte Strukturen, die für die Entwicklung von Metamodellen (mithilfe von CMOF) wie UML selbst verwendet wird. UML hat nur zwei Compliance-Ebenen - Modellgetriebene Architektur (MDA) Ein Ansatz für eine einheitliche Zusammenstellung modellgetriebener Technologiespezifikationen - Object Constraint Language (OCL) Eine deklarative Sprache für die Beschreibung von Regeln, die für die Unified Modeling Language gelten. OCL ergänzt UML durch Begriffe und Flussdiagramm-Symbole, die präziser sind als natürliche Sprache, aber nicht so komplex wie Mathematik - Object Management Group (OMG) ist ein nicht gewinnorientiertes Konsortium für die Entwicklung von Standards in der Computerbranche, deren Mitglieder die UML-Spezifikation definieren und verwalten - UML 1 Erste Version der Unified Modeling Language - Unified Modeling Language (UML) Eine visuelle Sprache für die Spezifizierung, Konstruktion und Dokumentation der Artefakte in einem System - XMI Eine XML-basierte Spezifikation von zugehörigen Modellaustauschformaten

Von UML festgelegte Modellierungskonzepte

Die Systementwicklung konzentriert sich im Großen und Ganzen auf drei unterschiedliche Systemmodelle:

• Funktional: Hierbei handelt es sich um Anwendungsfalldiagramme, welche die Systemfunktionalität aus Sicht des Benutzers beschreiben.

• Objekt: Hierbei handelt es sich um Klassendiagramme, welche die Systemstruktur im Hinblick auf Objekte, Attribute, Assoziationen und Vorgänge beschreiben.

• Dynamisch: Interaktionsdiagramme, Zustandsdiagramme und Aktivitätsdiagramme werden verwendet, um das interne Verhalten eines Systems zu beschreiben.

Für die Visualisierung solcher Systemmodelle verwendet man zwei unterschiedliche Diagrammarten: Struktur- und Verhaltensdiagramme.

Objektorientierte Konzepte in UML

Die Objekte in der UML sind Entitäten, die auch in der Realität existieren. In der Softwareentwicklung können Objekte dafür verwendet werden, um das zu erstellende System so zu beschreiben oder zu modellieren, dass es für die Domain relevant ist. Objekte ermöglichen außerdem die Zerlegung komplexer Systeme in verständliche Komponenten, sodass immer nur ein Teilbereich dargestellt wird.

Hier sind einige grundlegende Konzepte einer objektorientierten Welt:

• Objekte Repräsentation einer Entität und des jeweiligen Grundbausteins.

• Klasse Plan eines Objekts.

• Abstraktion Verhalten einer Entität aus der echten Welt.

• Verkapselung Mechanismus, bei dem Daten zusammengefügt werden, um diese vor der Außenwelt zu verbergen.

• Vererbung Der Mechanismus, bei dem neue Klassen aus einer vorhandenen erstellt werden.

• Polymorphismus Definiert den Mechanismus, der angewendet wird, um unterschiedliche Formen anzunehmen.

Arten von UML-Diagrammen

UML verwendet Elemente und verknüpft diese auf unterschiedliche Art und Weise miteinander, um verschiedene Arten von Diagrammen zu erstellen: zum einen Diagramme, die statische oder strukturelle Aspekte eines Systems darstellen, zum anderen verhaltensbasierte Diagramme, die die dynamischen Aspekte eines Systems erfassen.

Strukturelle UML-Diagramme

• Klassendiagramm Das am häufigsten verwendete UML-Diagramm und die wichtigste Grundlage für jede objektorientierte Lösung. Klassen in einem System, Attribute und Vorgänge sowie die Beziehung zwischen den einzelnen Klassen. Klassen werden gruppiert, um Klassendiagramme zu erstellen, wenn große Systeme als Diagramm dargestellt werden sollen.

Zwischen Objekten entstehen Assoziationen und Kardinalität (Kann- oder Muss-Beziehung). Eine Assoziation könnte auch eine Rolle haben, die die Funktion eines Objektes im Zusammenhang mit der dieser Assoziation beschreibt. (z.B. Kunde als Rolle des “Auftragsgebers”)

Bei dem Begriff “Richtunge” unterscheiden sich “Unidirektional” und “Bidirektional”. Beim ersteren kennt eine Klasse alle ihre assoziierten Klassen, diese wissen aber nicht, mit wem sie verbunden sind. Beim letzteren kennen verbundene Objekte sich gegenseitig.

Der Begriff “Aggregation” stellt eine Beziehung zwischen einem ganzen und seinen Teilen dar. “Komposition” ist Spezialfall der Aggregation . Einzelteile können nur mit dem Aggregat existieren. Ein Einzelteil kann nur genau einem Aggregat zugeordnet werden.

• Komponentendiagramm Stellt die strukturelle Beziehung von Softwaresystemelementen dar. Wird am häufigsten für komplexe Systeme mit mehreren Komponenten eingesetzt. Komponenten kommunizieren über Schnittstellen.

• Kompositionsstrukturdiagramm Kompositionsstrukturdiagramme werden verwendet, um die interne Struktur einer Klasse darzustellen.

• Implementierungsdiagramm Illustriert die Systemhardware und die zugehörige Software. Nützlich, wenn eine Softwarelösung auf mehreren Maschinen mit individuellen Konfigurationen implementiert wird.

• Objektdiagramm Zeigt die Beziehung zwischen Objekten unter Verwendung von Beispielen aus der Realität. Hierbei wird illustriert, wie ein System zu einem bestimmten Zeitpunkt aussieht. Da Daten in Objekten zur Verfügung stehen, können diese ebenfalls dafür verwendet werden, um Beziehungen zwischen Objekten zu verdeutlichen.

• Paketdiagramm Es gibt zwei spezielle Arten von Abhängigkeiten, die zwischen Paketen definiert werden: Paketimporte und Paketverschmelzungen. Pakete können die unterschiedlichen Ebenen eines Systems darstellen, um die Architektur zu visualisieren. Paketabhängigkeiten können so dargestellt werden, dass die Kommunikationsmechanismen zwischen verschiedenen Schichten erkennbar sind.

Verhaltensbasierte UML-Diagramme

• Aktivitätsdiagramme Grafisch dargestellte Geschäfts- oder Betriebsabläufe, um die Aktivität eines Teils oder einer Komponente in einem System zu visualisieren. Aktivitätsdiagramme werden alternativ zu Zustandsdiagrammen verwendet.

• Kommunikationsdiagramm Ähnelt dem Sequenzdiagramm, allerdings liegt der Fokus hier auf der Nachricht, die zwischen Objekten weitergegeben wird. Die gleichen Informationen lassen sich mit einem Sequenzdiagramm und unterschiedlichen Objekten darstellen.

• Interaktionsübersichtsdiagramm Es gibt sieben Arten von Interaktionsdiagrammen und dieses Diagramm zeigt die Abfolgesequenz von Aktionen im modellierten System.

• Sequenzdiagramm Zeigt, wie und in welcher Reihenfolge Objekte miteinander interagieren. Solche Diagramme repräsentieren Interaktionen für ein bestimmtes Szenario.

• Zustandsdiagramm Ähnlich wie Aktivitätsdiagramme beschreibt diese Art von Diagramm das Verhalten von Objekten, die in ihrem aktuellen Zustand unterschiedliche Verhaltensweisen an den Tag legen.

• Zeitverlaufsdiagramm Wie bei Sequenzdiagrammen wird hier das Verhalten von Objekten in einem bestimmten Zeitraum dargestellt. Wenn es nur ein einziges Objekt gibt, ist das Diagramm recht simpel. Bei mehr als einem Objekt werden die Interaktionen der Objekte während des festgelegten Zeitraums dargestellt.

• Anwendungsfalldiagramm Stellt eine bestimmte Funktionalität eines Systems dar und wurde entwickelt, um zu illustrieren, wie Funktionen zueinander in Beziehung stehen und welche internen/externen Akteure es gibt.

Subject: Das zu erstellende System. Akteur (actor): Der Benutzer und das externe System. Anwendungsfall (Use case): Anforderung an das Systemverhalten.