UML-Diagramm

Inhalt

 [Verstecken]  

• 1 Geschichte
• 1.1 Vor UML 1.x
• 1.2 UML 1.x
• 1.3 UML 2.x
• 2 Entwurf
• 2.1 Methoden der Software-Entwicklung
• 2.2 Modellierung
• 3 Diagramme
• 3.1 Strukturdiagramme
• 3.2 Verhaltensdiagramme
• 3.2.1 Interaktionsdiagramme
• 4 Meta-Modellierung
• 5 Annahme
• 6 Kritikpunkte
• 6.1 Kritik an UML 1.x

Geschichte[Quelle bearbeiten | bearbeiten]

Geschichte der objektorientierten Methoden und Notation

Die UML hat sich seit der zweiten Hälfte der 1990er Jahre entwickelt und hat ihre Wurzeln in den objektorientierten Methoden, die in den späten 1980er und frühen 1990er Jahren entwickelt wurden. Die Zeitleiste (siehe Bild) zeigt die Höhepunkte der Geschichte der objektorientierten Modellierungsmethoden und der Notation.

Es basiert ursprünglich auf den Notationen der Booch-Methode, der Objektmodellierungstechnik (OMT) und der objektorientierten Softwaretechnik (OOSE), die es in einer einzigen Sprache integriert hat. ^[5]

Vor UML 1.x[Quelle bearbeiten | bearbeiten]

Die Rational Software Corporation stellte James Rumbaugh 1994 von General Electric ein, und danach wurde die Firma zur Quelle für zwei der populärsten objektorientierten Modellierungsansätze der damaligen Zeit:^[6] Rumbaughs Objektmodellierungstechnik (OMT) und Grady Boochs Methode. Bei ihren Bemühungen wurden sie bald von Ivar Jacobson, dem Erfinder der Methode des objektorientierten Software-Engineering (OOSE), unterstützt, der 1995 bei Rational zu ihnen stieß.^[1]

Unter der technischen Leitung dieser drei (Rumbaugh, Jacobson und Booch) wurde 1996 ein Konsortium mit dem Namen UML Partnerswas organisiert, um die Spezifikation der Unified Modeling Language (UML) zu vervollständigen und sie der Object Management Group (OMG) zur Standardisierung vorzuschlagen. Die Partnerschaft umfasste auch weitere interessierte Parteien (z.B. HP, DEC, IBM und Microsoft). Der Entwurf der UML 1.0 der UML-Partner wurde der OMG im Januar 1997 vom Konsortium vorgeschlagen. Im selben Monat bildeten die UML-Partner eine Gruppe, die unter dem Vorsitz von Cris Kobryn und unter der Leitung von Ed Eykholt die genaue Bedeutung von Sprachkonstrukten definieren sollte, um die Spezifikation fertig zu stellen und sie in andere Standardisierungsbemühungen zu integrieren. Das Ergebnis dieser Arbeit, UML 1.1, wurde der OMG im August 1997 vorgelegt und im November 1997 von der OMG angenommen.^[1][7]

UML 1.x[Quelle bearbeiten | bearbeiten]

Nach der ersten Veröffentlichung wurde eine Arbeitsgruppe^[1] zur Verbesserung der Sprache gebildet, die mehrere kleinere Revisionen, 1.3, 1.4 und 1.5, veröffentlichte^[8].

Die von ihr erarbeiteten Standards (wie auch der ursprüngliche Standard) wurden als zweideutig und inkonsistent bezeichnet. ^[9][10]

UML 2.x[Quelle bearbeiten | bearbeiten]

Die Hauptrevision der UML 2.0 ersetzte 2005 die Version 1.5, die mit einem erweiterten Konsortium entwickelt wurde, um die Sprache weiter zu verbessern und neue Erfahrungen bei der Verwendung ihrer Funktionen zu berücksichtigen. ^[11]

Obwohl UML 2.1 nie als formale Spezifikation veröffentlicht wurde, erschienen die Versionen 2.1.1 und 2.1.2 im Jahr 2007, gefolgt von UML 2.2 im Februar 2009. UML 2.3 wurde im Mai 2010 formell freigegeben.^[12] UML 2.4.1 wurde im August 2011 formell freigegeben.^[12] UML 2.5 wurde im Oktober 2012 als "In Bearbeitung"-Version veröffentlicht und im Juni 2015 offiziell freigegeben.^[12] UML 2.5 wurde im Oktober 2012 als "In Bearbeitung"-Version freigegeben.

Die UML 2.x-Spezifikation besteht aus vier Teilen:

1. Der Überbau, der die Notation und Semantik für Diagramme und ihre Modellelemente definiert
2. Die Infrastruktur, die das Kernmetamodell definiert, auf dem der Überbau basiert
3. Die Object Constraint Language (OCL) zur Definition von Regeln für Modellelemente
4. Der UML-Diagrammaustausch, der definiert, wie UML-2-Diagrammlayouts ausgetauscht werden

Die aktuellen Versionen dieser Standards folgen: UML Superstructure Version 2.4.1, UML Infrastructure Version 2.4.1, OCL Version 2.3.1 und UML Diagram Interchange Version 1.0.^[13] Sie wird weiterhin von der Revisionstask Force aktualisiert und verbessert, die alle Probleme mit der Sprache löst. ^[14]

Entwurf[Quelle bearbeiten | bearbeiten]

Die Unified Modeling Language (UML) bietet eine Möglichkeit, die Architekturentwürfe eines Systems in einem Diagramm zu visualisieren (siehe Bild), einschließlich Elementen wie:^[5]

• Jegliche Aktivitäten (Jobs)
• Einzelne Komponenten des Systems
• Und wie sie mit anderen Softwarekomponenten interagieren können.
• Wie das System laufen wird
• Wie Entitäten mit anderen interagieren (Komponenten und Schnittstellen)
• Externe Benutzerschnittstelle

Obwohl die Unified Modeling Language (UML) ursprünglich nur für objektorientierte Designdokumentation gedacht war, wurde sie erweitert, um einen größeren Satz von Designdokumentation (wie oben aufgeführt) abzudecken^[15], und hat sich in vielen Kontexten als nützlich erwiesen. [^16]

Software-Entwicklungsmethoden[Quelle bearbeiten | bearbeiten]

UML ist keine Entwicklungsmethode an sich; ^[17] sie wurde jedoch so konzipiert, dass sie mit den führenden objektorientierten Softwareentwicklungsmethoden ihrer Zeit (z.B.OMT, Booch-Methode, Objectory) und insbesondere mit RUP kompatibel ist, für deren Einsatz sie ursprünglich bei Beginn der Arbeiten bei Rational Software Inc. vorgesehen war.

Modellierung[Quelle bearbeiten | bearbeiten]

Es ist wichtig, zwischen dem UML-Modell und der Menge der Diagramme eines Systems zu unterscheiden. Ein Diagramm ist eine teilweise grafische Darstellung des Modells eines Systems. Der Satz von Diagrammen muss das Modell nicht vollständig abdecken, und das Löschen eines Diagramms ändert das Modell nicht. Das Modell kann auch Dokumentation enthalten, die die Modellelemente und Diagramme steuert (z. B. schriftliche Anwendungsfälle).

UML-Diagramme stellen zwei verschiedene Sichten auf ein Systemmodell dar:^[18]

• Statische (oder strukturelle) Ansicht: Betont die statische Struktur des Systems mit Objekten, Attributen, Operationen und Beziehungen. Die Strukturansicht umfasst Klassendiagramme und zusammengesetzte Strukturdiagramme.
• Dynamische (oder verhaltensbasierte) Ansicht: betont das dynamische Verhalten des Systems, indem Kollaborationen zwischen Objekten und Änderungen der internen Zustände von Objekten gezeigt werden. Diese Ansicht umfasst Sequenzdiagramme, Aktivitätsdiagramme und Zustandsmaschinendiagramme.

UML-Modelle können zwischen UML-Tools ausgetauscht werden, indem das XML Metadata Interchange (XMI)-Austauschformat verwendet wird.

Diagramme[Quelle bearbeiten | bearbeiten]

In UML 2 gibt es viele Arten von Diagrammen, die in zwei Kategorien unterteilt sind. ^5] Einige Typen stellen strukturelle Informationen dar, und die übrigen stellen allgemeine Verhaltenstypen dar, darunter einige wenige, die verschiedene Aspekte von Interaktionen darstellen. Diese Diagramme können wie im folgenden Klassendiagramm hierarchisch kategorisiert werden:^[5]

Diese Diagramme können alle Kommentare oder Anmerkungen enthalten, die die Verwendung, Einschränkung oder Absicht erklären.

Strukturdiagramme[Quelle bearbeiten | bearbeiten]

Strukturdiagramme heben die Dinge hervor, die in dem zu modellierenden System vorhanden sein müssen. Da Strukturdiagramme die Struktur darstellen, werden sie in großem Umfang zur Dokumentation der Software-Architektur von Softwaresystemen verwendet. Zum Beispiel das Komponentendiagramm, das beschreibt, wie ein Softwaresystem in Komponenten aufgeteilt ist, und die Abhängigkeiten zwischen diesen Komponenten aufzeigt.

• Komponenten-Diagramm
• Klassendiagramm

Verhaltensdiagramme[Quelle bearbeiten | bearbeiten]

Verhaltensdiagramme verdeutlichen, was in dem zu modellierenden System geschehen muss. Da Verhaltensdiagramme das Verhalten eines Systems veranschaulichen, werden sie ausgiebig zur Beschreibung der Funktionalität von Softwaresystemen verwendet. Als Beispiel beschreibt das Aktivitätsdiagramm die geschäftlichen und betrieblichen Schritt-für-Schritt-Aktivitäten der Komponenten in einem System.

• Aktivitätsdiagramm
• Anwendungsfall-Diagramm

Interaktionsdiagramme[Quelle bearbeiten | bearbeiten]

Interaktionsdiagramme, eine Teilmenge von Verhaltensdiagrammen, betonen den Kontroll- und Datenfluss unter den Dingen im modellierten System. Zum Beispiel das Sequenzdiagramm, das zeigt, wie Objekte in Form einer Sequenz von Nachrichten miteinander kommunizieren.

• Sequenz-Diagramm
• Diagramm zur Kommunikation

Meta-Modellierung[Quelle bearbeiten | bearbeiten]

Hauptartikel: Meta-Objekt-Anlage

Illustration der Meta-Objekt-Anlage

Die Object Management Group (OMG) hat eine Metamodellierungsarchitektur entwickelt, um die Unified Modeling Language (UML), die so genannte Meta-Object Facility (MOF), zu definieren. ^[19] Die Meta-Object Facility ist als vierschichtige Architektur konzipiert, wie in der Abbildung rechts dargestellt. Sie bietet ein Meta-Meta-Modell auf der obersten Schicht, der so genannten M3-Schicht. Dieses M3-Modell ist die Sprache, die von der Meta-Object Facility zur Erstellung von Metamodellen, den sogenannten M2-Modellen, verwendet wird.

Das bekannteste Beispiel für ein Layer-2-Meta-Object Facility-Modell ist das UML-Metamodell, das Modell, das die UML selbst beschreibt. Diese M2-Modelle beschreiben Elemente der M1-Schicht und damit M1-Modelle. Dies wären zum Beispiel Modelle, die in UML geschrieben sind. Die letzte Schicht ist die M0-Schicht oder Datenschicht. Sie wird zur Beschreibung von Laufzeitinstanzen des Systems verwendet. ^[20]

Das Metamodell kann durch einen Mechanismus erweitert werden, der als Stereotypisierung bezeichnet wird. Dies ist von Brian Henderson-Sellers und Cesar Gonzalez-Perez in "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0" als unzulänglich/untentwickelbar kritisiert worden. ^[21]

Übernahme[Quelle bearbeiten | bearbeiten]

UML hat sich in vielen Designkontexten als nützlich erwiesen,^[16] so sehr, dass sie in der IT-Gemeinschaft nahezu allgegenwärtig geworden ist. ^[22]

Sie wurde zeitweise als eine Wunderwaffe des Designs behandelt, was zu Problemen bei ihrer Verwendung geführt hat. Zum Missbrauch gehört auch die übermäßige Verwendung (jeden kleinen Teil des Systemcodes mit ihm entwerfen, was unnötig ist) und die Annahme, dass jeder alles damit entwerfen kann (auch diejenigen, die nicht programmiert haben). ^[23]

Sie wird als eine große Sprache mit vielen Konstrukten angesehen. Einige (einschließlich Jacobson) haben das Gefühl, dass es zu viele sind und dass dies das Erlernen (und damit den Gebrauch) der Sprache behindert. ^[24]

Kritiken[Quelle bearbeiten | bearbeiten]

Zu den häufigsten Kritikpunkten der Industrie an der UML gehören:^[4]

• nicht nützlich: "[bietet] ihnen keine Vorteile gegenüber ihren gegenwärtigen, weiterentwickelten Praktiken und Darstellungen"
• zu komplex, insbesondere für die Kommunikation mit Kunden: "unnötig komplex" und "Der beste Grund, UML nicht zu verwenden, ist, dass sie nicht für alle Beteiligten 'lesbar' ist. Wie viel ist UML wert, wenn ein Geschäftsanwender (der Kunde) das Ergebnis Ihres Modellierungsaufwands nicht verstehen kann?
• Notwendigkeit, UML und Code synchron zu halten, wie bei der Dokumentation im Allgemeinen

Kritik an UML 1.x[Quelle bearbeiten | bearbeiten]

Kardinalitäts-Notation

Wie bei den Datenbankdiagrammen Chen, Bachman und ISO ER-Diagrammen sind die Klassenmodelle so spezifiziert, dass sie "Look-across"-Kardinalitäten verwenden, auch wenn mehrere Autoren (Merise,^[25] Elmasri & Navathe[26] u.a.[27]⁾ für Rollen und sowohl minimale als auch maximale Kardinalitäten die gleiche Seite oder "Look-here" bevorzugen. Neuere Forscher (Feinerer,^[28] Dullea u.a.^[29]) haben gezeigt, dass die von UML- und ER-Diagrammen verwendete "Look-across"-Technik weniger effektiv und weniger kohärent ist, wenn sie auf n-fache Beziehungen der Ordnung >2 angewendet wird.

Feinerer sagt: "Probleme entstehen, wenn wir nach der Look-across-Semantik arbeiten, wie sie für UML-Assoziationen verwendet wird. Hartmann^[30] untersucht diese Situation und zeigt, wie und warum verschiedene Transformationen scheitern. (Obwohl die erwähnte "Reduktion" fälschlicherweise ist, da die beiden Diagramme 3.4 und 3.5 in Wirklichkeit die gleichen sind) und auch "Wie wir auf den nächsten Seiten sehen werden, führt die Look-across-Interpretation mehrere Schwierigkeiten ein, die die Erweiterung einfacher Mechanismen von binären zu n-ary-Assoziationen verhindern".