UML mit Enterprise Architect
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 Diagrammtypen 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 Struktur und Verhalten des Systems dargestellt und somit Angriffspunkte für eine Optimierung der Lösung geboten.
UML-Diagramme
Diagramme sind wichtige Elemente in der UML. Informieren Sie sich hier über alle Diagramm-Arten im Überblick.
Dokumentation
Ein wesentlicher Punkt von UML ist die Möglichkeit, Diagramme als Teil der Projektdokumentation verwenden zu können. Diese können in vielfältiger Weise 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.
Vorteile von UML
Verbesserung der Zusammenarbeit
Reduzierung der Kosten während der Implementierungsphase
Enorme Zeitersparnis durch Roundtrip Engineering
Auch für Organisationsprojekte einsetzbar
Die Verwendung von UML als “gemeinsame Sprache” führt zu einer Verbesserung der Zusammenarbeit zwischen Technikern und Nicht-Technikern, darunter fallen Projektleiter, Business Analysten, Software-/Hardwarearchitekten, -designer und -entwickler. UML 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 Roundtrip 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.
Auch eine Anwendung bei Softwareprojekten ohne objektorientierte Sprachen oder bei Hardwareprojekten ist möglich und sinnvoll.
Enterprise Architect kaufen
Sie arbeiten mit einer älteren Version von Enterprise Architect und möchten auf die aktuelleste Version aktualisieren? Hier finden Sie eine Übersicht der Lizenzpreise im direkten Vergleich.
UML Standard
Die offizielle Spezifikation der UML 2.4.1 ist ein komplexes, über tausend Seiten umfassendes Werk (http://uml.org/) und ist formal in folgende Teilspezifikationen gegliedert:
- Infrastructure (Kern der Architektur, Profiles, Stereotype),
- Superstructure (statische und dynamische Modellelemente),
- OCL (Object Constraint Language) und
- Diagram Interchange (UML-Austauschformat)
Der vorliegende Text 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.
UML Erweiterung 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, Arbeitsaufträ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.
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 Anwendungsbereiche 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 Modelling 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.
Modelling 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 Modelling Language (UML) einen Quasi-Standard. 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. Die Version 2.3 wurde 2010 zum Standard, die derzeit aktuelle Version 2.5.1. im Dezember 2017. (Quelle: OOSE)
UML Diagrammtypen
UML Standard
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 Paketsymbol, 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) Diagramm-Name 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.5 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.
UML-Diagramme
Diagramme sind wichtige Elemente in der UML. Informieren Sie sich hier über alle Diagramm-Arten im Überblick.
Grundlagen der Verhaltensmodellierung
Bei der Modellierung von Verhalten geht es um die Beschreibung von Abläufen, zeitlichen Abhängigkeiten, Zustandsänderungen, der Verarbeitung von Ereignissen und Ähnlichem. Die UML ist objektorientiert, d. h., Verhalten ist nichts, was eigenständig existiert, sondern es betrifft immer konkrete Objekte. Die Ausführung eines Verhaltens lässt sich im Detail immer auf ein Objekt zurückführen.
Jedes Verhalten resultiert aus Aktionen mindestens eines Objektes und führt zu Zustandsänderungen der beteiligten Objekte.
Verhalten ist in der UML grundsätzlich ereignisorientiert. Die Ausführung von Verhalten wird stets durch ein Ereignis ausgelöst. Zwei besondere Ereignisse treten immer auf: das Startereignis und das Terminierungsereignis.
Verhalten kann entweder direkt gestartet werden, dies wird Verhaltensaufruf-Ereignis (CallBehaviorEvent) genannt, oder indirekt durch einen Trigger (TriggerEvent), beispielsweise Erreichen eines Zeitpunktes (TimeEvent), Nachrichtenempfang (ReceivingEvent) oder Erreichen bzw. Änderung eines bestimmten Wertes (ChangeEvent).
In der UML sind vier verschiedene Ausprägungen von Verhaltensbeschreibungen vorgesehen:
- Zustandsdiagramme (state machines)
- Aktivitäten und Aktionen (activities)
- Interaktionen (interaction)
- Anwendungsfälle (use cases)
Ein Anwendungsfalldiagramm ist eigentlich ein Strukturdiagramm, weil das Anwendungsfalldiagramm selbst keine Abläufe und Verhaltensweisen beschreibt, sondern nur die Struktur (Beziehungen) von Anwendungsfällen und Akteuren. In vielen Publikationen zur UML wird das Anwendungsfalldiagramm dennoch als Verhaltensdiagramm eingestuft. Sein Inhalt betrifft die gewünschte Funktionalität.
UML mit Enterprise Architect
In unserem Basis-Training lernen Sie die Modellierungssprache Unified Modelling Language (UML) für die konzeptionelle Modellierung mit Enterprise Architect anhand praktischer Beispiele bestmöglich einzusetzen.
