UML steht fürUnified Modeling Language. Es ist eine standardisierte Modellierungssprache, die aus einer integrierten Reihe von Diagrammen besteht, die entwickelt wurden, um System- und Softwareentwickler bei der Spezifikation, Visualisierung, Erstellung und Dokumentation der Artefakte von Software-Systemen sowie bei der Geschäftsmodellierung und anderen nicht-softwarebasierten Systemen zu unterstützen.

UML stellt eine Sammlung der besten ingenieurwissenschaftlichen Praktiken dar, die sich bei der Modellierung großer, komplexer Systeme als erfolgreich erwiesen haben. UML ist ein wichtiger Bestandteil der Entwicklung objektorientierter Software und des Softwareentwicklungsprozesses. UML verwendet hauptsächlich grafische Notationen, um die Gestaltung von Softwareprojekten auszudrücken. Die Verwendung von UML hilft Projektteams, sich zu verständigen, potenzielle Designs zu erkunden und die architektonische Gestaltung der Software zu validieren. In diesem Artikel geben wir detaillierte Informationen darüber, was UML ist.

Ursprünge von UML

Das Ziel von UML besteht darin, eine Standardnotation bereitzustellen, die von allen objektorientierten Methoden verwendet werden kann, und die besten Elemente früherer Notationen auszuwählen und zu integrieren. UML ist für eine breite Palette von Anwendungen konzipiert. Daher bietet es Konstrukte für eine Vielzahl von Systemen und Aktivitäten (z. B. verteilte Systeme, Analyse, Systemdesign und Bereitstellung).

UML entstand aus der Vereinigung dreier führender objektorientierter Modellierungssprachen:

1. Objektmodellierungstechnik (OMT) [James Rumbaugh 1991] – am besten geeignet für Analyse und datenintensive Informationssysteme.
2. Booch [Grady Booch 1994] – sehr stark bei Design und Implementierung. Grady Booch arbeitete ausführlich mit derAdaSprache und war ein wesentlicher Beitragender zur objektorientierten Entwicklung dieser Sprache. Obwohl die Booch-Methode leistungsfähig war, war ihre Notation nicht sehr populär (viele Wolkenformen in seinen Modellen – nicht sehr sauber).
3. OOSE (objektorientierte Softwaretechnik [Ivar Jacobson 1992]) – gekennzeichnet durch ein Modell namens Use Cases. Use Cases sind eine leistungsfähige Technik, um das Verhalten des gesamten Systems zu verstehen (ein Bereich, in dem OO traditionell schwach war).

Im Jahr 1994 wurde die Softwarewelt erschüttert, als Jim Rumbaugh, der Schöpfer von OMT, General Electric verließ und Grady Booch bei Rational Software beitrat. Die Zusammenarbeit hatte zum Ziel, ihre Ideen zu einer einheitlichen Methode zu vereinen (Arbeitstitel war „Unified Method“).

Bis 1995 trat auch Ivar Jacobson, der Schöpfer von OOSE, Rational bei, und seine Ideen (insbesondere das Konzept der „Use Cases“) wurden in die neue einheitliche Methode integriert – nun als Unified Modeling Language 1 bekannt. Das Team aus Rumbaugh, Booch und Jacobson wurde liebevoll als „Three Amigos“ bezeichnet.

UML wurde auch von anderen objektorientierten Notationen zu dieser Zeit beeinflusst:

• Mellor und Shlaer [1998]
• Coad und Yourdon [1995]
• Wirfs-Brock [1990]
• Martin und Odell [1992]

UML enthielt auch neue Konzepte, die in anderen führenden Methoden dieser Zeit nicht vorhanden waren, wie beispielsweise Erweiterungsmechanismen und Einschränkungssprachen.

Geschichte von UML

1. Während 1996 stellte dieObject Management Group (OMG)den ersten Antrag auf Vorschlag (RFP) heraus, der als Katalysator dafür diente, dass diese Organisationen gemeinsam auf einen RFP-Antworten reagierten.
2. Rational gründete die UML-Partner-Konsortium mit mehreren Organisationen, die bereit waren, Ressourcen für eine starke Definition von UML 1.0 einzusetzen. Zu den wichtigsten Beiträgern zur Definition von UML 1.0 gehörten:
   • Digital Equipment Corporation
   • Hewlett-Packard
   • I-Logix
   • IntelliCorp
   • IBM
   • ICON Computing
   • MCI Systemhouse
   • Microsoft
   • Oracle
   • Rational Software
   • Texas Instruments
   • Unisys
3. Diese Zusammenarbeit erzeugte UML 1.0, eine gut definierte, ausdrucksstarke, leistungsfähige und allgemein verwendbare Modellierungssprache. Sie wurde im Januar 1997 als erste Antwort auf die RFP bei OMG eingereicht.
4. Im Januar 1997 reichten IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies und Softeam ebenfalls getrennte RFP-Antworten bei OMG ein. Diese Unternehmen schlossen sich den UML-Partnern an, um ihre Ideen beizutragen, und die Partner erstellten gemeinsam eine überarbeitete UML-1.1-Antwort. UML 1.1 konzentrierte sich auf die Verbesserung der Klarheit der Semantik von UML 1.0 und die Einbeziehung von Beiträgen der neuen Partner. Sie wurde zur Prüfung bei OMG eingereicht und im Herbst 1997 übernommen. Die Versionen entwickelten sich von 1.1 bis 1.5, gefolgt von UML 2.0 bis 2.5 (aktuelle Version ist UML 2.5).

Warum UML?

Da der strategische Wert von Software für viele Unternehmen zunahm, suchte die Branche Technologien, um die Softwareerstellung zu automatisieren und die Qualität zu verbessern, während gleichzeitig Kosten und Zeit bis zur Markteinführung reduziert wurden. Zu diesen Technologien gehören Komponententechnologie, visuelles Programmieren, Muster und Frameworks. Unternehmen suchen ebenfalls nach Wegen, die Komplexität zu bewältigen, wenn ihre Reichweite und Skalierung zunehmen. Insbesondere erkennen sie die Notwendigkeit, wiederkehrende architektonische Probleme wie physische Verteilung, Konkurrenz, Replikation, Sicherheit, Lastverteilung und Fehlertoleranz zu lösen. Darüber hinaus hat die Entwicklung des World Wide Web, obwohl sie einige Dinge vereinfacht hat, diese architektonischen Probleme verschärft. Die Unified Modeling Language (UML) wurde entwickelt, um diesen Bedürfnissen gerecht zu werden.

1. Bieten Sie den Benutzern eine sofort einsetzbare, ausdrucksstarke visuelle Modellierungssprache, um sinnvolle Modelle zu erstellen und auszutauschen.
2. Bieten Sie Erweiterbarkeits- und Spezialisierungsmechanismen, um Kernkonzepte zu erweitern.
3. Unabhängig von bestimmten Programmiersprachen und Entwicklungsprozessen sein.
4. Bieten Sie eine formale Grundlage für das Verständnis der Modellierungssprache.
5. Förderung des Wachstums des markt für objektorientierte Werkzeuge.
6. Unterstützung von höheren Entwicklungskonzepten wie Zusammenarbeit, Frameworks, Mustern und Komponenten.
7. Best Practices integrieren.

UML – Übersicht

Bevor wir uns mit der UML-Theorie beschäftigen, lassen Sie uns kurz einige der wichtigsten Konzepte in UML vorstellen.

Das Erste, was man bei UML bemerken muss, ist, dass es viele verschiedene Diagramme (Modelle) gibt, an die man sich gewöhnen muss. Der Grund dafür ist, dass ein System aus vielen verschiedenen Perspektiven betrachtet werden kann. Die Softwareentwicklung beinhaltet viele Beteiligte.

Zum Beispiel:

• Analysten
• Designer
• Programmierer
• Testberater
• QA
• Kunden
• Technische Autoren

Alle diese Personen interessieren sich für verschiedene Aspekte des Systems, und jeder Aspekt erfordert ein unterschiedliches Maß an Detailgenauigkeit. Zum Beispiel müssen Programmierer das Design des Systems verstehen und in niedrigstufigen Code übersetzen können. Im Gegensatz dazu interessieren sich technische Autoren für das Gesamtverhalten des Systems und müssen die Funktionalität des Produkts verstehen. UML versucht, eine ausdrucksstarke Sprache bereitzustellen, sodass alle Beteiligten mindestens ein UML-Diagramm nutzen können.

Hier ist eine kurze Übersicht über jedes der 13 Diagramme, die in der UML 2-Diagrammstruktur gezeigt werden:

Strukturelle Diagramme zeigen die statische Struktur des Systems und seiner Teile auf verschiedenen Abstraktions- und Implementierungsebenen sowie deren Beziehungen. Strukturelle Diagramme haben sieben Arten:

• Klassendiagramm
• Komponentendiagramm
• Bereitstellungsdigramm
• Objektdiagramm
• Paketdiagramm
• Kompositstrukturdiagramm
• Profil-Diagramm

Verhaltensdiagramme zeigen das dynamische Verhalten von Objekten im System, das als eine Reihe von Veränderungen über Zeit. Es gibt sieben Arten von Verhaltensdiagrammen:

• Anwendungsfalldiagramm
• Aktivitätsdiagramm
• Zustandsautomatendiagramm
• Sequenzdiagramm
• Kommunikationsdiagramm
• Interaktionsübersichtsdiagramm
• Zeitdiagramm

Was ist ein Klassendiagramm?

Ein Klassendiagramm ist eine zentrale Modellierungstechnik, die in nahezu allen objektorientierten Methoden verwendet wird. Das Diagramm beschreibt die Arten von Objekten im System und die verschiedenen statischen Beziehungen, die zwischen ihnen bestehen.

Beziehungen

Es gibt drei wichtige Hauptbeziehungen:

1. Assoziation – zeigt eine Beziehung zwischen Instanzen von Typen an (z. B. eine Person arbeitet für ein Unternehmen, ein Unternehmen hat mehrere Niederlassungen).
2. Vererbung – die offensichtlichste Ergänzung zu ER-Diagrammen, die in der objektorientierten Programmierung verwendet werden. Sie entspricht direkt der Vererbung im objektorientierten Design.
3. Aggregation – eine Form der Objektkomposition im objektorientierten Design.

Klassendiagramm-Beispiel

Für weitere Details zu Klassendiagrammen lesen Sie den Artikel Was ist ein Klassendiagramm?

Was ist ein Komponentendiagramm?

Im Unified Modeling Language zeigt ein Komponentendiagramm, wie Komponenten miteinander verdrahtet werden, um größere Komponenten oder Software-Systeme zu bilden. Es veranschaulicht die Architektur von Software-Komponenten und deren Abhängigkeiten. Zu diesen Software-Komponenten gehören Laufzeit-Komponenten, ausführbare Komponenten sowie auch Quellcode-Komponenten.

Komponentendiagramm-Beispiel

Für weitere Details zu Komponentendiagrammen lesen Sie den Artikel Was ist ein Komponentendiagramm?

Was ist ein Bereitstellungsdigramm?

Bereitstellungsdigramme helfen dabei, die physischen Aspekte objektorientierter Software-Systeme zu modellieren. Es handelt sich um ein Strukturdiagramm, das die Architektur des Systems als Bereitstellung (Verteilung) von Software-Artefakten auf Bereitstellungsziele darstellt. Artefakte stellen konkrete Elemente in der physischen Welt dar, die aus dem Entwicklungsprozess hervorgehen. Es modelliert die Laufzeitkonfiguration in einer statischen Ansicht und visualisiert die Verteilung von Artefakten in einer Anwendung. In den meisten Fällen beinhaltet es die Modellierung von Hardware-Konfigurationen und der darauf befindlichen Software-Komponenten.

Bereitstellungsdigramm-Beispiel

Für weitere Details zu Bereitstellungsdigrammen lesen Sie den Artikel Was ist ein Bereitstellungsdigramm?

Was ist ein Objektdiagramm?

Ein Objektdiagramm ist ein Graph von Instanzen, einschließlich Objekten und Datenwerten. Ein statisches Objektdiagramm ist eine Instanz eines Klassendiagramms; es zeigt einen Schnappschuss des detaillierten Zustands des Systems zu einem bestimmten Zeitpunkt. Der Unterschied besteht darin, dass ein Klassendiagramm ein abstraktes Modell aus Klassen und ihren Beziehungen darstellt, während ein Objektdiagramm Instanzen zu einem bestimmten Moment darstellt, was inhärent konkret ist. Die Verwendung von Objektdiagrammen ist ziemlich begrenzt und dient hauptsächlich dazu, Beispiele für Datenstrukturen zu zeigen.

Klassendiagramm gegenüber Objektdiagramm – Ein Beispiel

Einige Menschen finden es schwierig, den Unterschied zwischen UML-Klassendiagrammen und UML-Objektdiagrammen zu verstehen, da beide benannte „rechteckige Blöcke“ mit Attributen und Verbindungen zwischen ihnen enthalten, was die beiden UML-Diagramme ähnlich erscheinen lässt. Manche halten sie sogar für identisch, da in UML-Tools sowohl die Symbole für Klassendiagramme als auch für Objektdiagramme im selben Diagramm-Editor – dem Klassendiagramm – platziert werden.

In Wirklichkeit stellen Klassendiagramme und Objektdiagramme zwei verschiedene Aspekte des Codebases dar. In diesem Artikel geben wir einige Ideen zu diesen beiden UML-Diagrammen, was sie sind, wie sie sich unterscheiden und wann man sie verwenden sollte.

Beziehung zwischen Klassendiagramm und Objektdiagramm

Sie erstellen „Klassen“ beim Programmieren. Zum Beispiel können Sie in einem Online-Banking-System Klassen wie „Benutzer“, „Konto“, „Transaktion“ usw. erstellen. In einem Klassensystem können Sie Klassen wie „Lehrer“, „Schüler“, „Aufgabe“ usw. erstellen. In jeder Klasse gibt es Attribute und Operationen, die die Eigenschaften und Verhaltensweisen der Klasse darstellen. Ein Klassendiagramm ist ein UML-Diagramm, in dem Sie diese Klassen, ihre Attribute, Operationen und deren Beziehungen zueinander visualisieren können.

Ein UML-Objektdiagramm zeigt, wie Instanzen von Objekten (in einem UML-Klassendiagramm gezeichnet) zu einem bestimmten Zustand „aussehen“. Mit anderen Worten kann ein UML-Objektdiagramm als eine Instanz betrachtet werden, wie Klassen (in einem UML-Klassendiagramm) zu einem bestimmten Zustand verwendet werden.

Wenn Ihnen diese Definitionen nicht gefallen, werfen Sie einen Blick auf die UML-Diagramm-Beispiele unten. Ich glaube, Sie werden ihren Unterschied in Sekunden verstehen.

Klassendiagramm-Beispiel

Das folgende Klassendiagramm-Beispiel stellt zwei Klassen dar – Benutzer und Anhang. Ein Benutzer kann mehrere Anhänge hochladen, daher sind die beiden Klassen über eine Assoziation mit der Vielzahl 0…* auf der Seite des Anhangs verbunden.

Objektdiagramm-Beispiel

Das folgende Objektdiagramm-Beispiel zeigt, wie Objekt-Instanzen der Klassen Benutzer und Anhang „aussehen“, wenn Peter (also ein Benutzer) versucht, zwei Anhänge hochzuladen. Es gibt also zwei Instanzspezifikationen für die beiden hochzuladenden Anhänge.

Für weitere Details zu Objektdiagrammen lesen Sie den Artikel Was ist ein Objektdiagramm?

Was ist ein Paketdiagramm?

Ein Paketdiagramm ist ein UML-Strukturdiagramm, das Pakete und Abhängigkeiten zwischen Paketen zeigt. Paketdiagramme ermöglichen die Darstellung verschiedener Sichten eines Systems, z. B. als mehrschichtiges (auch mehrstufiges) Anwendungssystem – mehrschichtiges Anwendungsmuster.

Beispiel für ein Paketdiagramm

Für weitere Informationen zu Paketdiagrammen lesen Sie den Artikel Was ist ein Paketdiagramm?

Was ist ein Zusammensetzungsstrukturdiagramm?

Zusammensetzungsstrukturdiagramme sind eines der neuen Artefakte, die in UML 2.0 hinzugefügt wurden. Ein Zusammensetzungsstrukturdiagramm ähnelt einem Klassendiagramm und ist eine Art Komponentendiagramm, das hauptsächlich zur Modellierung eines Systems aus mikroskopischer Sicht verwendet wird, jedoch zeigt es die interne Struktur eines einzelnen Teils und nicht die gesamte Klasse. Es ist ein statisches Strukturdiagramm, das die interne Struktur einer Klasse und die Zusammenarbeit, die diese Struktur ermöglicht, darstellt.

Das Diagramm kann interne Teile, Ports, über die Teile miteinander interagieren oder Instanzen der Klasse mit der Außenwelt interagieren, sowie Verbindungen zwischen Teilen oder Ports enthalten. Eine Zusammensetzungsstruktur ist eine Menge miteinander verbundener Elemente, die zur Erreichung eines Zwecks zur Laufzeit zusammenarbeiten. Jedes Element hat eine definierte Rolle in der Zusammenarbeit.

Beispiel für ein Zusammensetzungsstrukturdiagramm

Für weitere Informationen zu Zusammensetzungsstrukturdiagrammen lesen Sie den Artikel Was ist ein Zusammensetzungsstrukturdiagramm?

Was ist ein Profildiagramm?

Mit dem Profildiagramm können Sie domänen- und plattformspezifische Stereotypen erstellen und deren Beziehungen definieren. Sie können Stereotypen durch Zeichnen von Stereotypformen erstellen und sie über eine ressourcenorientierte Schnittstelle mit Zusammensetzung oder Generalisierung verknüpfen. Sie können außerdem markierte Werte von Stereotypen definieren und darstellen.

Beispiel für ein Profildiagramm

Für weitere Informationen zu Profildiagrammen lesen Sie den Artikel Was ist ein Profildiagramm in UML?

Was ist ein Use-Case-Diagramm?

Ein Use-Case-Modell beschreibt die funktionalen Anforderungen eines Systems in Form von Use-Cases. Es ist ein Modell der beabsichtigten Funktionen des Systems (Use-Cases) und seiner Umgebung (Aktoren). Use-Cases ermöglichen es, das, was das System tun muss, mit der Art und Weise zu verbinden, wie das System diese Anforderungen erfüllt.

Stellen Sie sich ein Use-Case-Modell wie eine Speisekarte vor, wie man sie in einem Restaurant findet. Wenn Sie die Speisekarte betrachten, können Sie sehen, welche Gerichte verfügbar sind, einzelne Gerichte und deren Preise. Sie erfahren auch, welche Art von Küche das Restaurant anbietet: italienisch, mexikanisch, chinesisch usw. Wenn Sie die Speisekarte betrachten, erhalten Sie einen Gesamteindruck davon, welche gastronomische Erfahrung Sie in diesem Restaurant erwartet. Die Speisekarte „nachahmt“ tatsächlich das Verhalten des Restaurants.

Da es ein so leistungsfähiges Planungswerkzeug ist, verwenden alle Teammitglieder Use-Case-Modelle während aller Phasen des Entwicklungszyklus.

Beispiel für ein Use-Case-Diagramm

Für weitere Informationen zu Use-Case-Diagrammen lesen Sie den Artikel Was ist ein Use-Case-Diagramm?

Was ist ein Aktivitätsdiagramm?

Ein Aktivitätsdiagramm ist eine grafische Darstellung von Abläufen von schrittweisen Aktivitäten und Aktionen mit Unterstützung für Auswahl, Iteration und Konkurrenz. Es beschreibt den Steuerfluss des Zielsystems, z. B. die Erforschung komplexer Geschäftsregeln und -operationen, die Beschreibung von Use-Cases und Geschäftsprozesse. Im Unified Modeling Language sollen Aktivitätsdiagramme sowohl rechnerische als auch organisatorische Prozesse (d. h. Workflows) modellieren.

Beispiel für ein Aktivitätsdiagramm

Für weitere Informationen zu Aktivitätsdiagrammen lesen Sie den Artikel Was ist ein Aktivitätsdiagramm?

Was ist ein Zustandsautomatendiagramm?

Ein Zustandsdiagramm ist eine Art von Diagramm, das in UML verwendet wird, um das Systemverhalten basierend auf dem Zustandsdiagramm-Konzept von David Harel zu beschreiben. Zustandsdiagramme zeigen zulässige Zustände und Übergänge sowie die Ereignisse, die diese Übergänge beeinflussen. Es hilft dabei, die gesamte Lebenszyklus eines Objekts zu visualisieren, wodurch das Verständnis von zustandsbasierten Systemen verbessert wird.

Beispiel für ein Zustandsmaschinen-Diagramm

Für weitere Details zu Zustandsmaschinen-Diagrammen lesen Sie den Artikel Was ist ein Zustandsmaschinen-Diagramm?

Was ist ein Sequenzdiagramm?

Ein Sequenzdiagramm modelliert die Zusammenarbeit von Objekten nach zeitlicher Abfolge. Es zeigt, wie Objekte in einem bestimmten Anwendungsszenario miteinander interagieren. Mit erweiterten visuellen Modellierungsmöglichkeiten können Sie komplexe Sequenzdiagramme mit nur wenigen Klicks erstellen. Außerdem können einige Modellierungswerkzeuge (wie Visual Paradigm) Sequenzdiagramme aus dem Ereignisablauf generieren, den Sie in den Anwendungsszenario-Beschreibungen definiert haben.

Beispiel für ein Sequenzdiagramm

Für weitere Details zu Sequenzdiagrammen lesen Sie den Artikel Was ist ein Sequenzdiagramm?

Was ist ein Kommunikationsdiagramm?

Ähnlich wie ein Sequenzdiagramm wird auch ein Kommunikationsdiagramm verwendet, um das dynamische Verhalten eines Anwendungsfalls zu modellieren. Im Vergleich zu Sequenzdiagrammen legen Kommunikationsdiagramme mehr Wert darauf, die Zusammenarbeit von Objekten darzustellen, anstatt die zeitliche Abfolge. Sie sind semantisch äquivalent, sodass einige Modellierungswerkzeuge (wie Visual Paradigm) es ermöglichen, eines aus dem anderen zu generieren.

Beispiel für ein Kommunikationsdiagramm

Für weitere Details zu Kommunikationsdiagrammen lesen Sie den Artikel Was ist ein Kommunikationsdiagramm?

Was ist ein Interaktionsübersichtsdiagramm?

Ein Interaktionsübersichtsdiagramm konzentriert sich auf eine Übersicht über den Steuerfluss der Interaktion. Es ist eine Variante des Aktivitätsdiagramms, bei dem die Knoten Interaktionen oder Interaktionsvorkommen sind. Das Interaktionsübersichtsdiagramm beschreibt die Interaktionen, bei denen Nachrichten und Lebenslinien verborgen sind. Sie können auf „echte“ Diagramme verweisen und eine hohe Navigierbarkeit zwischen Diagrammen im Interaktionsübersichtsdiagramm erreichen.

Beispiel für ein Interaktionsübersichtsdiagramm

Für weitere Details zu Interaktionsübersichtsdiagrammen lesen Sie den Artikel Was ist ein Interaktionsübersichtsdiagramm?

Was ist ein Zeitdiagramm?

Ein Zeitdiagramm zeigt das Verhalten von Objekten über einen bestimmten Zeitraum. Zeitdiagramme sind eine spezielle Form von Sequenzdiagrammen. Der Unterschied zwischen Zeitdiagrammen und Sequenzdiagrammen besteht darin, dass die Achsen umgekehrt sind, sodass die Zeit von links nach rechts zunimmt, und Lebenslinien in vertikal angeordneten getrennten Kammern dargestellt werden.

Beispiel für ein Zeitdiagramm

Für weitere Details zu Zeitdiagrammen lesen Sie den Artikel Was ist ein Zeitdiagramm?

Lernen Sie UML. Zeichnen Sie UML.

Holen Sie sich die Visual Paradigm Community Edition – ein KOSTENLOSES UML-Tool, das Ihnen hilft, UML schneller und effektiver zu lernen. Die Visual Paradigm Community Edition unterstützt alle UML-Diagrammtypen. Ihr preisgekrönter UML-Modellierer ist intuitiv und einfach zu bedienen.

Kostenloser Download

UML-Wörterbuch und Terminologie

• Abstrakte Klasse – Eine Klasse, die niemals instanziert wird. Es existieren niemals Instanzen dieser Klasse.
• Aktor – Ein Objekt oder eine Person, die Ereignisse auslöst, die mit dem System verbunden sind.
• Aktivität: Ein Schritt oder eine Aktion in einem Aktivitätsdiagramm. Stellt eine Operation dar, die vom System oder einem Akteur ausgeführt wird.
• Aktivitätsdiagramm: Ein verfeinertes Flussdiagramm, das Schritte und Entscheidungen in einem Prozess sowie parallele Operationen, wie z. B. einen Algorithmus oder einen Geschäftsprozess, zeigt.
• Aggregation – Ist Teil einer anderen Klasse. Wird im Diagramm durch ein hohles Diamant-Symbol neben der enthaltenden Klasse dargestellt.
• Artefakt – Ein Dokument, das die Ausgabe eines Schritts im Entwurfsprozess beschreibt. Die Beschreibung kann grafisch, textuell oder eine Kombination aus beiden sein.
• Assoziation – Eine Verbindung zwischen zwei Elementen im Modell. Dies könnte eine Member-Variable im Code, eine Assoziation zwischen einem Personalakte und der Person, die sie darstellt, eine Beziehung zwischen zwei Klassen von Arbeitnehmern oder eine ähnliche Beziehung darstellen. Standardmäßig kennen sich beide Elemente in einer Assoziation gegenseitig und sind gleichwertig. Eine Assoziation kann auch navigierbar sein, was bedeutet, dass der Quellendpunkt den Zielendpunkt kennt, aber nicht umgekehrt.
• Assoziationsklasse: Eine Klasse, die eine Assoziation zwischen zwei anderen Klassen darstellt und ihr zusätzliche Informationen hinzufügt.
• Attribut – Eine Eigenschaft eines Objekts, die verwendet werden kann, um auf andere Objekte zu verweisen oder Informationen über den Zustand des Objekts zu speichern.
• Basisklasse: Die Klasse, die Attribute und Operationen definiert, die von Unterklassen über eine Verallgemeinerungsbeziehung vererbt werden.
• Verzweigung: Ein Entscheidungspunkt in einem Aktivitätsdiagramm. Aus einer Verzweigung gehen mehrere Übergänge hervor, jeder mit einer Wächterbedingung. Wenn die Steuerung die Verzweigung erreicht, muss genau eine Wächterbedingung wahr sein, und die Steuerung folgt dem entsprechenden Übergang.
• Klasse: Eine Kategorie ähnlicher Objekte, die alle durch dieselben Attribute und Operationen beschrieben werden und alle zueinander zuweisbar sind.
• Klassendiagramm – Zeigt Klassen im System und die Beziehungen zwischen ihnen.
• Klassifizierer: Ein UML-Element, das Attribute und Operationen besitzt. Speziell: Akteure, Klassen und Schnittstellen.
• Kooperation: Eine Beziehung zwischen zwei Objekten in einem Kommunikationsdiagramm, die anzeigt, dass Nachrichten zwischen den Objekten hin und her übertragen werden können.
• Kommunikationsdiagramm – Ein Diagramm, das zeigt, wie eine Operation ausgeführt wird, wobei die Rollen der Objekte betont werden.
• Komponente: Eine bereitstellbare Einheit von Code im System.
• Komponentendiagramm: Ein Diagramm, das Beziehungen zwischen verschiedenen Komponenten und Schnittstellen zeigt.
• Konzept – Ein Substantiv oder abstraktes Konzept, das in das Domänenmodell aufgenommen werden soll.
• Aufbauphase – Die dritte Phase des Rational Unified Process, in der mehrere funktionale Iterationen im aufgebauten System erstellt werden. Hier findet der größte Teil der Arbeit statt.
• Abhängigkeit: Eine Beziehung, die darauf hinweist, dass ein Klassifikator über die Attribute und Operationen eines anderen Klassifikators Bescheid weiß, aber nicht direkt mit Instanzen des zweiten Klassifikators verbunden ist.
• Bereitstellungsdigramm: Ein Diagramm, das Beziehungen zwischen verschiedenen Prozessoren zeigt.
• Domäne – Der Teil der Diskurswelt, mit dem das System verbunden ist.
• Erprobungsphase – Die zweite Phase des Rational Unified Process, die zusätzliche Projektplanung ermöglicht, einschließlich Iterationen in der Aufbauphase.
• Element: Ein beliebiges Element, das im Modell dargestellt wird.
• Kapselung – Daten innerhalb eines Objekts sind privat.
• Generalisierung – Zeigt an, dass eine Klasse eine Unterklasse einer anderen (Superklasse) ist. Ein hohler Pfeil zeigt auf die Superklasse.
• Ereignis: In einem Zustandsdiagramm stellt dies ein Signal oder Ereignis oder eine Eingabe dar, die dazu führt, dass das System eine Aktion ausführt oder seinen Zustand ändert.
• Endzustand: In einem Zustandsdiagramm oder Aktivitätsdiagramm stellt dies den Punkt dar, an dem das Diagramm abgeschlossen ist.
• Verzweigung: Ein Punkt in einem Aktivitätsdiagramm, an dem mehrere parallele Steuerungsfäden beginnen.
• Generalisierung: Eine Vererbungsbeziehung, bei der eine Unterklasse Attribute und Operationen einer Basisklasse erbt und erweitert.
• GoF – Gang of Four-Entwurfsmuster.
• Hohe Kohäsion – Ein GRASP-Evaluationsmuster, das sicherstellt, dass eine Klasse nicht zu komplex ist und keine unzusammenhängenden Funktionen ausführt.
• Niedrige Kopplung – Ein GRASP-Evaluationsmuster, das das Maß angibt, in dem eine Klasse von einer anderen Klasse abhängt oder mit ihr verbunden ist.
• Inception-Phase – Die erste Phase des Rational Unified Process, die sich mit der ersten Konzeptualisierung und dem Beginn des Projekts befasst.
• Vererbung – Eine Unterklasse erbt Attribute oder Merkmale von ihrer Elternklasse (Superklasse). Diese Attribute können in der Unterklasse überschrieben werden.
• Anfangszustand: In einem Zustandsdiagramm oder Aktivitätsdiagramm stellt dies den Punkt dar, an dem das Diagramm beginnt.
• Instanz – Ein Objekt ist eine Instanz einer Klasse. Die Klasse wirkt wie eine Vorlage zum Erstellen von Objekten. Es können beliebig viele Instanzen der Klasse erstellt werden.
• Schnittstelle: Ein Klassifizierer, der Attribute und Operationen definiert, die einen Verhaltensvertrag bilden. Eine Anbieterklasse oder -komponente kann die Schnittstelle wählen, um sie zu realisieren (d. h. ihre Attribute und Operationen zu implementieren). Client-Klassen oder -komponenten können dann von der Schnittstelle abhängen und somit den Anbieter nutzen, ohne Kenntnis über Details der tatsächlichen Anbieterklasse zu haben.
• Iteration – Ein kleiner Teil eines Projekts, bei dem eine kleine Funktionalität hinzugefügt wird. Beinhaltet einen Entwicklungszyklus aus Analyse, Design und Codierung.
• Verbindung: Ein Punkt in einem Aktivitätsdiagramm, an dem mehrere parallele Steuerungsfäden synchronisiert und wieder zusammengeführt werden.
• Member: Ein Attribut oder eine Operation in einem Klassifizierer.
• Verschmelzung: Ein Punkt in einem Aktivitätsdiagramm, an dem verschiedene Steuerungspfade zusammenkommen.
• Nachricht – Eine Anfrage eines Objekts an ein anderes, um das empfangende Objekt aufzufordern, eine Aktion auszuführen. Dies ist im Wesentlichen ein Aufruf einer Methode im empfangenden Objekt.
• Methode – Eine Funktion oder Prozedur in einem Objekt.
• Modell – Das zentrale UML-Artefakt. Bestehend aus verschiedenen Elementen, die in Hierarchien angeordnet sind und Beziehungen zwischen den Elementen aufweisen.
• Vielfachheit – Wird neben dem externen Konzeptkasten in einem Domänenmodell angezeigt und zeigt die quantitative Beziehung von Objekten zu anderen Objekten an.
• Navigation: Gibt an, welcher Endpunkt einer Beziehung den anderen Endpunkt kennt. Eine Beziehung kann bidirektionale Navigation (jeder Endpunkt kennt den anderen) oder einseitige Navigation (ein Endpunkt kennt den anderen, aber nicht umgekehrt) aufweisen.
• Notation – Grafische Dokumentation mit Regeln für die Erstellung von Analyse- und Entwurfsmethoden.
• Hinweis: Ein textlicher Kommentar, der einem Diagramm hinzugefügt wird, um das Diagramm detaillierter zu erklären.
• Objekt – In einem Aktivitätsdiagramm ein Objekt, das Informationen von einer Aktivität empfängt oder Informationen an eine Aktivität weitergibt. In einem Zusammenarbeit- oder Sequenzdiagramm ein Objekt, das an der in dem Diagramm beschriebenen Szene teilnimmt. Allgemein: eine Instanz oder ein Beispiel eines gegebenen Klassifizierers (Aktivität, Klasse oder Schnittstelle).
• Paket – Eine Gruppe von UML-Elementen, die logisch zusammengehören.
• Paketschema: Ein Klassendiagramm, bei dem alle Elemente Pakete und Abhängigkeiten sind.
• Muster – Eine Lösung für das Problem der Verantwortungszuweisung bei Objektinteraktionen. Es handelt sich um eine benannte Lösung für ein häufig auftretendes und gut bekanntes Problem.
• Parameter: Ein Parameter einer Operation.
• Polymorphismus – Gleiche Nachricht, verschiedene Methoden. Wird auch als Muster verwendet.
• Privat: Sichtbarkeitsstufe, die auf ein Attribut oder eine Operation angewendet wird und anzeigt, dass nur Code innerhalb des enthaltenden Klassifizierers auf das Mitglied zugreifen kann.
• Prozessor: In einem Bereitstellungsdigramm stellt dies einen Computer oder ein anderes programmierbares Gerät dar, auf dem Code bereitgestellt werden kann.
• Geschützt: Sichtbarkeitsstufe, die auf ein Attribut oder eine Operation angewendet wird und anzeigt, dass nur Code innerhalb des enthaltenden Klassifizierers oder seiner Unterklassen auf das Mitglied zugreifen kann.
• Öffentlich: Sichtbarkeitsstufe, die auf ein Attribut oder eine Operation angewendet wird und anzeigt, dass jeder Code auf das Mitglied zugreifen kann.
• Leserichtungspfeil – Gibt die Richtung einer Beziehung in einem Domänenmodell an.
• Realisierung: Gibt an, dass ein Komponente oder eine Klasse eine bestimmte Schnittstelle bereitstellt.
• Rolle – Wird in einem Domänenmodell verwendet, um eine optionale Beschreibung der Rolle zu geben, die ein Entität spielt.
• Sequenzdiagramm: Ein Diagramm, das die Existenz von Objekten über die Zeit und die Nachrichten, die zwischen diesen Objekten über die Zeit übermittelt werden, zur Ausführung einer bestimmten Aktion zeigt. Zustandsdiagramm – Ein Diagramm, das alle möglichen Zustände eines Objekts zeigt.
• Zustand: Im Zustandsdiagramm stellt dies einen Zustand oder eine Bedingung des Systems oder Subsystems dar: was es zu einem bestimmten Zeitpunkt tut und seine Datenwerte.
• Zustandsdiagramm: Ein Diagramm, das Zustände eines Systems oder Subsystems, Übergänge zwischen Zuständen und Ereignisse, die Übergänge verursachen, zeigt.
• Statisch: Ein Modifikator, der auf ein Attribut angewendet wird und anzeigt, dass nur eine Kopie des Attributs über alle Instanzen des Klassifizierers geteilt wird. Ein Modifikator, der auf eine Operation angewendet wird und anzeigt, dass die Operation unabhängig ist und nicht auf eine spezifische Instanz des Klassifizierers operiert.
• Stereotyp: Ein Modifikator, der auf ein Modell-Element angewendet wird und etwas anzeigt, das normalerweise nicht in UML ausgedrückt werden kann. Grundsätzlich ermöglichen Stereotypen die Definition Ihrer eigenen „Dialekt“ von UML.
• Unterklasse: Eine Klasse, die Attribute und Operationen erbt, die durch eine Verallgemeinerungsbeziehung von einer Oberklasse definiert sind.
• Schwimmkanal: Ein Element in einem Aktivitätsdiagramm, das angibt, welter Teil des Systems oder der Domäne für eine bestimmte Aktivität verantwortlich ist. Alle Aktivitäten in einem Schwimmkanal sind die Verantwortung des Objekts, der Komponente oder des Akteurs, der durch den Schwimmkanal repräsentiert wird.
• Zeitrahmen – Jede Iteration hat eine feste Zeitspanne mit einem spezifischen Ziel.
• Übergang: Im Aktivitätsdiagramm stellt dies den Steuerungsfluss von einer Aktivität oder Verzweigung oder Verschmelzung oder Verzweigung oder Verbindung zu einer anderen dar. Im Zustandsdiagramm stellt dies eine Änderung von einem Zustand zu einem anderen dar.
• Übergangsphase – Die letzte Phase des Rational Unified Process, in der Benutzer darauf trainiert werden, das neue System zu nutzen, und das System den Benutzern zur Verfügung gestellt wird.
• UML – Unified Modeling Language verbessert die Analyse und Gestaltung von Softwareprojekten, indem engere Beziehungen zwischen Objekten durch Text- und grafische Dokumentation ermöglicht werden.
• Anwendungsfalldiagramm: Im Anwendungsfalldiagramm stellt dies eine Aktion dar, die das System im Rahmen einer Anforderung eines Akteurs ausführt.
• Anwendungsfalldiagramm: Ein Diagramm, das Beziehungen zwischen Akteuren und Anwendungsfällen zeigt.
• Sichtbarkeit: Ein Modifikator für ein Attribut oder eine Operation, der angibt, welcher Code auf das Mitglied zugreifen kann. Sichtbarkeitsstufen umfassen Öffentlich, Geschützt und Privat.
• Arbeitsablauf – Eine Reihe von Aktivitäten, die ein bestimmtes Ergebnis erzeugen.

Beliebte UML-Bücher

Hier sind einige der meistverkauften UML-Bücher, die Sie lesen können, um UML zu lernen:

1. UML verdichtet: Eine kurze Einführung in die Standard-Sprache für objektorientierte Modellierung
2. UML 2 und der einheitliche Prozess: Praktische objektorientierte Analyse und Gestaltung
3. UML 2.0 lernen
4. Webanwendungen mit UML erstellen
5. Der Referenzhandbuch zur Unified Modeling Language
6. Die Elemente des UML™ 2.0-Stils
7. UML für Java-Programmierer
8. Schaum’s Übersicht über UML
9. Der Benutzerhandbuch zur Unified Modeling Language
10. UML 2-Zertifizierungshandbuch: Grundlagen- und Mittelstufe-Prüfungen
11. Grundlagen der objektorientierten Gestaltung in UML
12. Anwendung von use-case-getriebener objektorientierter Modellierung mit UML: Ein annotiertes Beispiel für E-Commerce
13. Entwicklung flexibler objektorientierter Systeme mit UML
14. Use-Case-getriebene objektorientierte Modellierung mit UML
15. Systemanalyse und -gestaltung mit UML Version 2.0: Ein objektorientierter Ansatz
16. UML 2.0 im Überblick
17. Objektorientierte Analyse und Gestaltung mit Anwendungen
18. UML erklärt
19. Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software
20. Der Objektpriemer: Agiles modellgetriebenes Entwickeln mit UML 2.0

Verwandte Links

1. Professionelles UML-Design-Tool für visuelle Modellierung