UML mit Enterprise Architect

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

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.

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)

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.