UML Diagramme für objektorientierte Modellierung

Fortschreitende Digitalisierung bewegt immer mehr Unternehmen dazu, ihre Geschäfts- und Produktionsprozesse mit komplexen digitalen Fundamenten auszustatten. Digitalisierte Produktionssysteme, CRM-Software, Mitarbeiterverwaltung, E-Commerce-Systeme und Online-Shops  rücken damit in den Fokus betrieblicher Wertschöpfungs- und Verwaltungsprozesse. Eine fundamentaler Faktor wird dabei aber oft vernachlässigt: Die langfristige Planung einer geeigneten Softwarearchitektur, die auch zum Kern der betrieblichen Wertschöpfungskette und den zugehörigen Prozessen passt. Mit einer Modellierung durch UML Diagramme lassen sich Planung, Konzeption und den Entwurf von Softwaresystemen auf den betrieblichen Kontext optimal abstimmen. Und das ist definitiv eines der wichtigsten Instrumente im Zeitalter von Industrie und Web 4.0!

In dieser mehrteiligen UML Guideline möchte ich die unternehmerischen und technischen Grundlagen für die Verwendung der weit verbreiteten UML Diagramme legen. So lässt sich vielleicht der ein oder andere Unternehmenslenker dazu bewegen, eine bedarfsgerechte Anforderungsanalyse samt zugehöriger Prozessmodellierung einzuleiten, bevor man sich Hals über KOpf in das nächste Digitalisierungs-Abenteuer stürzt.

Schließlich ist die Modellierung mit UML nicht nur ein zusätzlicher Kostenfaktor, sondern kann auch langfristig einen signifikanten Anteil an Kosten einsparen, wenn für die Zukunft weniger Liquidität in den selbst geschacherten Software-Gräbern versenkt wird. Es lohnt sich also, sich im Rahmen von Softwareprojekten mit den Modellierungsvarianten der UML Sprache zu beschäftigten. So läuft die Kommunikation zwischen Entwickler-Team und Stakeholdern viel einfacher.

Im Übrigen wird die UML von dem 1989 gegründeten OMG Konsortium (Object Management Group) entwickelt und genormt. Das Konsortium, zu deren Gründungsmitgliedern auch IBM, Apple und Sun gehören, ist für die Standardisierung von herstellerunabhängigen und systemübergreifenden objektorientierten Programmiersprachen zuständig. Dazu gehören auch Ansätze wie die Modellierung mit der BPMN-Methodik, die insbesondere in Banken, Unternehmensberatungen und Software-Firmen zum Einsatz kommt. Auch der weltweit verbreitete XML-Standard wird durch die OMG weiterentwickelt und verwaltet.

Was ist UML? Praxisbezug einer Modellierungssprache

In der Kurzfassung: Die UML (Unified Modeling Language) bzw. die zugehörigen UML-Diagramme sind eine visuelle Modellierungssprache für die bildhafte Gestaltung von (Geschäfts-) Prozessen, Vorgängen sowie statischen und dynamischen Beziehungen zwischen Objekten und Systemen. Diese Modellierung dient als Grundlage für Konzeption, Planung, Entwurf und Implementation von Softwarearchitektur, mit der die fachliche und technische Basis für komplexe Softwareanwendungen und Softwaresysteme gelegt wird.

Oder etwas vereinfacht ausgedrückt: Mit UML werden fachliche, formale und technische Anforderungen an eine Software bildhaft modelliert, damit eine verständliche Kommunikationsgrundlage zwischen den Software-Anwendern (bzw. Auftraggebern) und der ausführenden Softwareentwicklung geschaffen wird. Diese Grundlage dient dann als Basis für die erfolgreiche Planung, die Architektur, das Design und die Implementierung einer Software.

Diese Funktion der UML wird in der Praxis gerade von unternehmerischen Entscheidungsträgern massiv unterschätzt. Derartige Modellierungsprozesse werden entweder gar nicht erst bedacht oder als „formaler Ballast“ abgetan, um möglichst agil agieren zu können. Die gesparte Zeit wird dann vorzugsweise in die detaillierte Ausarbeitung umfangreicher Lastenhefte investiert – in der Hoffnung, dass diese Artefakte dem Auftragnehmer bei der Entwicklung einer Softwarelösung das beste Hilfsmittel darstellen.

Skizzieren wir diesen Vorgang einmal beispielhaft mit Praxisbezug, wie er gerade in kleinen und mittelständischen Unternehmen oftmals ablaufen dürfte:

1. Beim großen Meeting der Geschäftsführung etabliert sich eine neue Digitalstrategie, die auch die Umstrukturierung der eigenen Software-Landschaft samt der Neuentwicklung einer geeigneten Anwendungssoftware vorsieht. Die neue Software soll die Digitalisierung von Geschäftsprozessen vorantreiben und einen effizienten betrieblichen Workflow gewährleisten.
2. In der nächsten Phase wird eine Reihe an Fachanwendern zusammengetrommelt, die durch Köpfe aus der IT ergänzt wird (falls diese Köpfe überhaupt existieren. Die meisten kleinen Unternehmen haben natürlich keine eigene Inhouse-IT). Ziel der Mannschaft ist es, einen Anforderungskatalog zu definieren, mit denen ein detailliertes Lastenheft ausgearbeitet werden kann. Sobald die interne Validation abgeschlossen ist, wird ein geeigneter Partner für die Umsetzung des Software-Projekts ermittelt – sofern der ganze Spaß nicht Inhouse stattfindet.
3. Mit einem mehr oder wenigen klaren Anforderungskatalog, Lastenheft und einer Wunschvorstellung bewaffnet, beauftragt die Geschäftsführung eine Person oder größere Firma mit der Entwicklung und Einführung der neuen Softwarelösung.
4. Abhängig von Professionalität und Erfahrung des „Entwicklers“ können nun zwei Szenarien für den Entwicklungsprozess eintreten:

• Szenario 1: Der beauftragte Entwicklungsschmiede beginnt nach einigen Rücksprachen und der Ausfertigung eines zunächst passenden Pflichtenheftes mit der Implementation der Software anhand der besprochenen und beschriebenen Anforderungen und erzielt schon nach kurzer Zeit ein erstes lauffähiges Ergebnis, das die Geschäftsführung voller Euphorie und Zuversicht stimmt. Damit sind der weiteren Entwicklung alle Türen, Tore und Fallklappen geöffnet.
• Szenario 2: Die Entwicklungsschmiede lehnt eine direkte Umsetzung aufgrund unzureichend definierter Anforderungsbeschreibungen ab und bietet an, durch professionelle Begleitung einer fachlichen Schnittstelle beim Prozess der Anforderungsanalyse anzusetzen, um alle nötigen Gesichtspunkte für den Entwurf einer geeigneten Softwarearchitektur zusammen mit den Fachanwendern des Betriebs zu erarbeiten. Ein klassischer Rückschritt, der zunächst mit Mehraufwand und einem verlängerten Zeitplan verknüpft ist.

Worst Case und Use Case

Bleiben wir kurz bei Szenario 1, das auf den ersten Blick am besten klingt. Nach wenigen Wochen ist die Implementation der Software so weit fortgeschritten, dass eine Einführung und anschließende Migration der Systeme bevorsteht. Weil die Liquidität im Quartal der Einführung aber nicht allzu rosig ausfällt, entscheidet sich die Geschäftsführung dazu, die Einführung der neuen Software auf der (eigentlich zu alten) Bestandshardware auszuführen.

Gesagt getan. Wider Erwarten läuft die Einführung einigermaßen problemlos. Doch mit der Zeit häufen sich die Fehler. In der Zwischenzeit hat die Software-Schmiede aufgrund von Rechtsstreitigkeiten allerdings Insolvenz angemeldet, niemand ist mehr zu erreichen. Die Entwickler-CEOs sind im Ausland untergetaucht. Die neue Software zerlegt sich von selbst, eine operative Nutzung ist nicht mehr möglich. Die Geschäftsführung trifft den folgenschweren Entschluss, die neue und teure Software einzustellen und auf das alte System zu wechseln, damit der Betrieb nicht vollständig lahmgelegt wird.

Abhängig von der verbleibenden Liquidität und der Motivation der Geschäftsführung, wird der Prozess iteriert oder sogar vollständig eingestampft, womit sich das Thema Digitalisierung zunächst erledigt hätte. Das Worst Case Szenario für unseren Use Case (Anwendungsfall) ist eingetreten.

Idealerweise lernen wir (als Unternehmensleitung) aus den gemachten Fehlern und landen nun bei Szenario 2, das uns zunächst vor der digitalen Vollkatastrophe bewahrt und zum nächsten Punkt führt: einer ausführlichen Anforderungsanalyse.

Zugegeben – dieser schematische Praxisbezug ist in der Realität natürlich nicht immer bis ins Detail so abzubilden, zumal der Fachbezug, die Prozesse, Motivation und Anforderungen von Unternehmen zu Unternehmen völlig unterschiedlich sein können. Aber die ein oder andere Parallele wird hier vermutlich jeder Entscheider für sich oder sein Unternehmen erkennen können. Ziel war lediglich die Illustration eines Praxisbeispiels.

Kernaufgabe: Requirements Engineering

Kernaufgabe der UML Diagramme in Unternehmen und Software-Anwendungen ist somit die Vereinfachung der Kommunikation zwischen allen beteiligten Interessengruppen des Projektes. Im Rahmen des sog. „Requirements Engineerings“  (der Anforderungsanalyse) soll sichergestellt werden, dass sämtliche fachlichen Kriterien einer Software auch erfüllt werden können und dabei die Qualitätsmerkmale einer Software gewahrt bleiben.

Wir wissen alle: Fachanwender und Informatiker sprechen nur selten die gleiche Sprache. Und das liegt nicht nur an der lingualen Diskrepanz zwischen Business English und Java.

Das ist auch der Grund, warum die meisten Projekte, die auf Basis einfacher Fachkriterien und Lastenhefte umgesetzt werden, am Ende scheitern oder nur kurze Zeit Bestand haben. So wie sich der DAX-Chef nur selten aus seinen schallgeschützten Konferenzräumen und Limousinen drängen lässt, verharrt ein Programmierer oftmals in seiner objekt-orientierten Denkweise, die für den Fachanwender und die Stakeholder eines Software-Projektes aber nur selten nachvollziehbar ist.

Aus diesem Grund brauchen wir eine einheitliche Sprache, die als Schnittstelle zwischen fachlichen und technischen Anforderungen fungieren kann und die Sprache aller Interessengruppen so weit vereinheitlicht, dass im Kontext einer Anforderungsanalyse eine klare, verständliche und zielorientierte Kommunikation möglich ist.

Und genau hier setzt die UML als Unified Modeling Language an.

Wer die Modellierung mit UML beherrscht (oder korrekt interpretieren kann), ist in der Lage, fachliche und formelle Anforderungen an eine Software in eine objektorientierte Sprache zu fassen, mit der die objektorientierte Programmierung zielgerichtet arbeiten kann.

Oder Andersrum: Wenn die Programmierung auf Hindernisse oder Unklarheiten stößt, lässt sich, dank der UML Diagramme, mit den Fachanwendern und Stakeholdern eine zielführende Kommunikation und Lösungsfindung ermöglichen.

Die verschiedenen Typen der UML Diagramme

Genug der Motivation. Schauen wir uns die verschiedenen Typen der UML Diagramme etwas genauer an. Dabei fällt schnell auf, dass in der UML verschiedene Ansätze objektorientierter Notationen kombiniert werden. UML Diagramme lassen sich nach UML 2.3 in zwei grundlegende Diagramm-Typen einteilen:

• Strukturdiagramme
• Verhaltensdiagramme

Eine messerscharfe Trennung zwischen diesen Diagrammtypen ist aber nicht in allen Fällen möglich, was vielmehr an der engen funktionalen Verflechtung der einzelnen Diagramm-Typen liegt. Dazu aber später mehr in den separaten Ausführungen.

Strukturdiagramme:

• Klassendiagramme
• Komponentendiagramme
• Kompositionsstrukturdiagramme
• Verteilungsdiagramme
• Objektdiagramme
• Paketdiagramme
• Profildiagramme

Verhaltensdiagramme:

• Aktivitätsdiagramm
• Kommunikationsdiagramm
• Interaktionsübersichtsdiagramm
• Sequenzdiagramm
• Zustandsdiagramm
• Zeitverlaufsdiagramm
• Anwendungsfalldiagramm (Use-Case Diagramm)

Anforderungsanalyse mit Use Case Diagrammen

Letzteres ist das nächste Thema dieser UML Guideline. Denn aus den betrieblichen Anwendungsfällen mit echten Akteuren, Szenarios und Systemen ergibt sich eine wesentliche Grundlage der späteren Softwarearchitektur, weshalb hier eine detaillierte Modellierung der Anwendungsfälle absolut sinnvoll ist.

Wir beginnen also damit, die funktionalen Anforderungen an unser System formal zu definieren und legen eine sog. Use Case Beschreibung an, aus der sich ein grundlegendes Systemverhalten ableiten lässt. Diese formalen Beschreibungen dienen der Darstellung der Nutzerintention bzw. der Definition eines Zielvorhabens und können funktionale Abhängigkeiten in einem System und seinen Subsystemen beschreiben.