Einführung in UML
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.
Dokumentation
Ein wesentlicher Punkt von UML ist die Möglichkeit, Diagramme als Teil der Projektdokumentation 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.
Geschichtliche Entwicklung von UML
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)
Vorteile von UML
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.
UML Standard
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).
UML-Erweiterungen in Enterprise Architect
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.
UML Diagrammtypen
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-Diagramme im Überblick
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
Diagrammeinsatz
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 |
| |
Aktivitätsdiagramm (Activity Diagram) | Analyse- und Designphase |
| |
Paketdiagramm (Package Diagram) | Analyse- und Designphase |
| |
Klassendiagramm (Class Diagram) | Analyse- und Designphase |
| |
Sequenzdiagramm (Sequence Diagram) | Designphase |
| |
Kommunikationsdiagramm (Communication Diagram) | Designphase |
| |
Zustandsdiagramm (State Diagram) | Designphase |
| |
Komponentendiagramm | Designphase |
| |
Einsatz- und Verteilungsdiagramm (Deployment Diagram) | Designphase |
|
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.
Der Werkzeugcharakter von Enterprise Architect
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:
Projektzyklus
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 Prozessdarstellungen, 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.