UML ist eine standardisierte grafische Darstellungsform zur Visualisierung, Spezifikation, Konstruktion und Dokumentation von (Software-)Systemen. Sie bietet ein Set an standardisierten Diagrammtypen, mit denen komplexe Sachverhalte, Abläufe und Systeme einfach, übersichtlich und verständlich dargestellt werden können.

UML ist keine Vorgangsweise und auch kein Prozess, sie stellt lediglich ein „Wörterbuch“ an Symbolen zur Verfügung, von denen jedes eine definierte Bedeutung hat. Sie bietet Diagramm-typen für die objektorientierte Analyse, Design und Programmierung und gewährleistet somit einen nahtlosen Übergang von den Anforderungen an ein System bis zur fertigen Implementierung. Dabei werden die Struktur und das Verhalten des Systems dargestellt und somit Angriffspunkte für eine Optimierung der Lösung geboten.

Ein wesentlicher Punkt von UML ist die Möglichkeit, Diagramme als Teil der Projekt­doku­men­tation verwenden zu können. Diese können in vielfältigerweise Niederschlag in den verschiedensten Dokumenten finden, beispielsweise können Use Case Diagramme zur Beschreibung der funktionalen Anforderungen in die Anforderungsdefinition wandern. Klassen- bzw. Komponentendiagramme können als Softwarearchitektur im Designdokument verwendet werden. Grundsätzlich können UML Diagramme in praktisch jeder technischen Dokumentation (z. B. Testpläne) verwendet aber auch Teil des Benutzerhandbuches werden.

Obwohl die Idee der Objektorientierung über 30 Jahre alt ist und die Entwicklung objekt¬orientierter Programmiersprachen fast ebenso lange zurückliegt, erschienen die ersten Bücher über objektorientierte Analyse- und Designmethoden erst Anfang der 90er Jahre. Die Urväter dieser Idee waren Grady Booch, Ivar Jacobson und James Rumbaugh. Jeder dieser drei „Veteranen“ hatte seine eigene Methode entwickelt, die jedoch auf bestimmte Anwendungs¬bereiche spezialisiert und begrenzt war.

1995 begannen zunächst Booch und Rumbaugh, ihre Methoden in Form einer gemeinsamen Notation zur Unified Method (UM) zusammenzuführen. Die Unified Method wurde jedoch schon bald in Unified Modeling Language (UML) umbenannt, was auch eine angemessenere Bezeichnung darstellte, weil es sich im Wesentlichen nur um die Vereinheitlichung der grafischen Darstellung und Semantik der Modellierungselemente handelte und keine Methodik beschrieben wurde. Modeling Language ist im Grunde nur eine andere Umschreibung für Notation. Kurze Zeit später stieß auch Ivar Jacobson dazu, sodass die von ihm geprägten Use Cases (dt. Anwendungsfälle) integriert wurden. Die Drei nannten sich fortan „Amigos“.

Weil die Methoden von Booch, Rumbaugh und Jacobson bereits sehr populär waren und einen hohen Marktanteil hatten, bildete die Zusammenführung zur Unified Modeling Language (UML) einen Quasistandard. Schließlich wurde 1997 die UML in der Version 1.1 bei der Object Management Group (OMG) zur Standardisierung eingereicht und akzeptiert. Die Versionen 1.2 bis 1.5 enthalten jeweils einige Korrekturen. Die Version 2.0 ist seit 2004 als Standard verabschiedet worden und enthält einige wesentliche Änderungen und Erweiterungen. (Quelle: OOSE)

Die Verwendung von UML als "gemeinsame Sprache" führt zu einer Verbesserung der Zusammen¬arbeit zwischen Technikern und Nicht-Technikern, darunter fallen Projektleiter, Business Analysten, Softwarearchitekten, -designer und  entwickler. Sie hilft, Systeme besser zu verstehen, Möglichkeiten der Vereinfachung und/oder Wiederverwendbarkeit aufzudecken und mögliche Risiken besser zu erkennen. Durch frühzeitige Erkennung von Fehlern in der Analyse- bzw. Designphase eines Projekts können die Kosten während der Implementierungsphase verringert werden. Die Möglichkeit des Round¬trip Engineerings bietet vor allem für Entwickler eine enorme Zeitersparnis.

Obwohl UML ursprünglich für die Modellierung von Software-Systemen entwickelt worden ist, ist sie prinzipiell auch für Organisationsprojekte einsetzbar. Durch die Möglichkeit, Prozesse visualisieren zu können, ist es im Anschluss möglich, diese zu analysieren und zu verbessern.

Die offizielle Spezifikation der UML 2.1 ist ein komplexes, über tausend Seiten umfassendes Werk (http://uml.org/) und ist formal in folgende Teilspezifikationen gegliedert:

  • Infrastructure (Kern der Architektur, Profiles, Stereotypen),
  • Superstructure (statische und dynamische Modellelemente),
  • OCL (Object Constraint Language) und
  • Diagram Interchange (UML-Austauschformat)

 

Das vorliegende Buch deckt nur die wichtigsten Kernelemente der UML ab und stellt in keiner Weise eine vollständige und umfassende Referenz dar. Für weitergehende und vertiefende Details der UML wird an weiterführende Literatur verwiesen (siehe Anhang).

Enterprise Architect nutzt den in der UML vorgesehenen Erweiterungsmechanismus (Profile) um sowohl neue Elemente – z. B. ein Element für Requirement – als auch weitere Diagrammtypen zur Verfügung zu stellen. Ebenso werden erweiterte Properties – z. B. Fenster für Tests, Arbeits¬auf-träge, Risiken, usw. – bereitgestellt. Dadurch entsteht ein UML-basiertes Werkzeug, das zusammen mit einer auch integrierbaren Entwicklungsplattform die umfassende Projektarbeit inklusive Requirements Management, Betriebsdokumentation, usw. erlaubt.

Es existiert in der UML offiziell keine Diagrammübersicht oder -kategorisierung. Während UML-Modelle und das hinter den Diagrammen stehende Repository in der UML definiert sind, können Diagramme, d. h. spezielle Sichten auf das Repository, relativ frei definiert werden.

Ein Diagramm ist in der UML eigentlich mehr eine Sammlung von Notationselementen. So beschreibt beispielsweise das Paketdiagramm das Paket¬symbol, die Merge-Beziehung usw. Ein Klassendiagramm beschreibt Klasse, Assoziation usw. Trotzdem dürfen natürlich Klassen und Pakete in einem Diagramm gemeinsam dargestellt werden.

Ein Diagramm besteht aus einer von einem Rechteck umgebenen Diagrammfläche und einem Diagrammkopf in der linken oberen Ecke. Im Diagrammkopf steht (optional) Diagrammtyp, (obligatorisch) Diagrammname und (optional) Parameter.

Der Diagrammtyp ist beispielsweise sd für Sequenzdiagramme oder cd für Klassendiagramme. Das Parameterfeld ist für parametrisierbare Modelle wichtig.

UML in der Version 2.1 enthält 13 Diagrammtypen, die grob in zwei Gruppen unterteilt werden können. Die Gruppe der Strukturdiagramme stellt statische Aspekte eines Systems dar, die Gruppe der Verhaltensdiagramme die dynamischen Teile

Vielen UML-Neulingen stellt sich bald die Frage, in welchem Zusammenhang diese Diagramme stehen. Diese Frage ist absolut berechtigt, jedoch gibt uns UML darauf keine Antwort. Erst die Vorgangsweise bei der Softwareentwicklung, also der verwendete Prozess dahinter, kann diese Frage beantworten. Ein möglicher Ansatz, in welcher Reihenfolge, also in welchen Phasen eines Projekts, die Diagramme ihren Einsatz finden, gibt die folgende Aufstellung:

Anwendungsfalldiagramm (Use Case Diagram)

Analysephase

 
  • Welche Anwendungsfälle in der zu erstellenden Anwendung enthalten sind.
  • Welche Akteure diese Anwendungsfälle auslösen.
  • Welche Abhängigkeiten der Anwendungsfälle untereinander bestehen, z. B.:
    Ob ein Anwendungsfall in einem anderen enthalten ist.
    Ob ein Anwendungsfall eine Spezialisierung eines andern darstellt.Ob ein bestehender Anwendungsfall durch einen zweiten erweitert wird.
 

Aktivitätsdiagramm (Activity Diagram)

Analyse- und Designphase

 
  • Welche Schritte innerhalb eines Anwendungsfalls durchlaufen werden.
  • Welche Zustandsübergänge die beteiligten Objekte erfahren, wenn die Abarbeitung von einer Aktivität zur nächsten wechselt.
 

Paketdiagramm (Package Diagram)

Analyse- und Designphase

 
  • In welche Pakete die Anwendung zerlegt werden kann.
  • Welche Pakete eine weitere Unterteilung ermöglichen.
  • Welche Kommunikation zwischen den Paketen realisiert werden muss.
 

Klassendiagramm (Class Diagram)

Analyse- und Designphase

 
  • Welche Zusammenhänge bestehen in der Aufgabenstellung (Domainmodell).
  • Welche Klassen, Komponenten und Pakete beteiligt sind.
  • Über welche Kommunikation die Zusammenarbeit stattfindet.
  • Welche Methoden und Eigenschaften die Klassen benötigen.
  • Wie viele Objekte mindestens und höchstens in Verbindung stehen.
  • Welche Klassen als Container für mehrere Objekte zuständig sind.
 

Sequenzdiagramm (Sequence Diagram)

Designphase

 
  • Welche Methoden für die Kommunikation zwischen ausgewählten Objekten zuständig sind.
  • Wie der zeitliche Ablauf von Methodenaufrufen zwischen ausgewählten Objekten stattfindet.
  • Welche Objekte in einer Sequenz neu erstellt und / oder zerstört werden.
 

Kommunikationsdiagramm (Communication Diagram)

Designphase

 
  • Wie ausgewählte Objekte miteinander kommunizieren.
  • In welcher Reihenfolge die Methodenaufrufe stattfinden.
  • Welche alternativen Methodenaufrufe gegebenenfalls existieren.
 

Zustandsdiagramm (State Diagram)

Designphase

 
  • Welche Zustandsübergange von welchen Methodenaufrufen ausgelöst werden.
  • Welcher Zustand nach dem Erzeugen des Objekts eingenommen wird.
  • Welche Methoden das Objekt zerstören.
 

Komponentendiagramm

Designphase

 
  • Wie werden Soft- und/oder Hardwareteile mit definierter Funktion und definierten Interfaces gekapselt.
  • Welche Komponenten haben Interfaces zueinander.
  • Welche Softwarteteile erzeugen die Funktionalität in Komponenten.
 

Einsatz- und Verteilungsdiagramm (Deployment Diagram)

Designphase

 
  • Welche PCs in der Anwendung zusammenarbeiten.
  • Welche Module der Anwendung auf welchem PC ausgeführt werden.
  • Auf welchen Kommunikationsmöglichkeiten die Zusammenarbeit basiert.
 

Die Reihenfolge der Verwendung der Diagramme kann gegebenenfalls von der in der Tabelle angegebenen abweichen, weil z. B. keine Arbeitsteilung mehrerer Programmierer zu verwalten ist. In diesem Fall kann das Paketdiagramm erst mit dem Klassendiagramm erstellt werden. Mit der Reihenfolge soll nur eine Möglichkeit gezeigt werden, wie Sie zu einem Modell ihrer Anwendung kommen und die Überleitung der Phasen gestalten können.
Ebenso wird das Anwendungsgebiet eine Auswirkung haben, eine Business¬automatisierungs-aufgabe wird sich von in der entstehenden Diagrammfolge her von einer Embedded-Aufgabenstellung in der Reihenfolge der verwendeten Diagramme deutlich unterscheiden.

Enterprise Architect hat einerseits die Zielsetzung, UML-gerechtes Modellieren mit allen 13 UML-Basis-Diagrammtypen zu ermöglichen, andererseits soll das Werkzeug eine umfassende Arbeit und Dokumentation des kompletten Projektzyklus erlauben.

Vereinfacht kann ein Projektzyklus folgendermaßen dargestellt werden:

Ein Projektzyklus kann grob in fünf Abschnitte unterteilt werden, unabhängig davon, wie das Projektvorgehen des Anwenders gewählt wird (vom V-Modell bis zum iterativen Prototyping, etc.):
 

  • Analyse: Ermittlung des Istzustandes, Festschreibung der zu erbringenden Leistungen und Wirkungen und/oder der zu erbringenden Lösung aus funktionaler Sicht
  • Design: Lösungsfindung und Lösungsspezifikation in zunehmender Detailtiefe
  • Implementierung: Umsetzung der Lösung
  • Testen: Qualitätssicherung
  • Betrieb führen: Inbetriebsetzung und fortschreitender Betrieb

In der Praxis werden die Teilaufgaben mehr oder weniger stark zeitlich überlappend ausgeführt, je nach Art des Projektvorgehens. Jedenfalls zeitlich überlappend tritt „Tests ausführen“ auf.

Das dunkelgrau eingezeichnete Rechteck „UML Basisgrammatik“ nimmt Bezug auf die 13 UML-Basisdiagramme und dem UML-Basiselemente-Umfang. Im Abschnitt Analyse fällt in der Praxis auf, dass nahezu alle Betriebe ISO-Zertifizierungen für ihre Businessprozesse aufweisen, also die Prozesse dokumentiert haben. Diese Dokumentationen verwenden verschiedenste Prozess­darstellungen, z. B. EPK oder BPMN im angloamerikanischen Sprachraum, die dem eher puritanischen UML-Activity-Elementesatz vorgezogen werden. BPMN wurde daher in den EA mit eingebaut, die EPK-Symbole können mit einem Profil leicht ergänzt werden.

Am anderen Ende des UML-Basis-Grammatik-Rechteckes fällt auf, dass UML selbst keine Aussagen über Reverse-Engineering trifft. Daher wurden die Use Cases „Analyse durchführen“ und „Implementierung durchführen“ absichtlich über den Rand der UML-Basis-Grammatik-Systemgrenze gezogen.

Enterprise Architect adressiert – auf UML-Profilen basierend – den kompletten Projektzyklus: Daher gibt es im EA ergänzende Symbole und Diagrammarten.

Requirements Management wurde inkludiert, d. h., EA kann dieses Thema ohne zusätzliches Werkzeug mit voller Vernetzung und Nachvollziehbarkeit abwickeln, es kann aber auch ein Abgleich mit externen Requirements Managementsystemen durchgeführt werden, über XMI-Abgleich oder über das enthaltene Automation Interface. Eine integrative, importierende Erweiterung zu DOORS® ist auch verfügbar.

Grundlegende Projekt-Management-Funktionalität ist auch enthalten, es würde ja keinen besonderen Sinn machen, Informationen über den Umsetzungsstand getrennt zu führen. Auch hier bestehen Möglichkeiten, eine Verbindung zu Gantt-Programmen herzustellen.