Was ist UML?

UML ist eine visuelle Sprache zur Beschreibung von Softwaresystemen. Sie gibt Ihnen einen festen Satz an Formen, Linien und Regeln, damit ein Diagramm, das Sie zeichnen, dasselbe bedeutet für jemanden, der nicht in dem Raum sass, in dem es entstand.

Das ist das gesamte Wertversprechen, und man sollte es deutlich sagen. Ein Kasten mit einem Namen darin ist kein UML. Ein Kasten mit drei Abteilen, ein hohles Dreieck, das auf einen anderen Kasten zeigt, und ein 1..* an einem Linienende ist UML, und es sagt etwas Präzises: Dieser Typ erbt von jenem, und eine Instanz des ersten ist mit mindestens einer des zweiten verbunden. Jeder, der die Notation kennt, liest das identisch. Das ist es, was Sie kaufen.

Gepflegt wird die Sprache von der Object Management Group. Die aktuelle Ausgabe ist UML 2.5.1, veröffentlicht 2017. Sie stammt aus der Arbeit, die Grady Booch, James Rumbaugh und Ivar Jacobson Mitte der Neunziger bei Rational zusammenführten, als das Feld rund fünfzig konkurrierende Notationen hatte und keine Möglichkeit, den Entwurf eines anderen zu lesen. Die OMG übernahm UML 1.1 im Jahr 1997. Version 2.5 war weitgehend Aufräumarbeit: Die Spezifikation war in die Bände „infrastructure“ und „superstructure“ zerfallen, in denen sich kaum jemand zurechtfand, und 2.5 faltete sie zurück in ein Dokument.

Jedes UML-Diagramm beantwortet eine von zwei Fragen. Strukturdiagrammebeantworten „woraus besteht dieses System?“ - die Teile, die Typen, die Maschinen und wie sie angeordnet sind. Sie beschreiben Dinge, die unabhängig von der Zeit wahr sind.

Verhaltensdiagrammebeantworten „was tut dieses System?“ - die Flüsse, die Nachrichten, die Zustände und die Reihenfolge, in der Dinge geschehen. Sie beschreiben Dinge, die nur in einem Moment wahr sind.

Ein Klassendiagramm sagt Ihnen, dass ein Payment einen Betrag und einen Status hat. Ein Zustandsautomat sagt Ihnen, dass eine Zahlung von Authorized nach Captured geht, aber nie umgekehrt. Keines kann das andere ausdrücken, und die meisten echten Fragen brauchen je eines. Wenn Sie merken, dass Sie eine Reihenfolge auf einem Klassendiagramm zeigen wollen, ist das das Signal, ein zweites Diagramm zu zeichnen, statt das erste zu überladen.

Verhalten hat eine zusätzliche Verschachtelungsebene. Vier der sieben Verhaltensdiagramme - Sequenz, Kommunikation, Zeitverlauf und Interaktionsübersicht - sind allesamt Interaktionsdiagramme, vier verschiedene Darstellungen derselben zugrunde liegenden Idee: Beteiligte tauschen Nachrichten aus. Im Prinzip sind sie austauschbar. In der Praxis dominieren Sequenzdiagramme, weil eine senkrechte Zeitachse das Leichteste ist, was sich lesen lässt.

Hier ist die gesamte Sprache auf der Ebene von „brauche ich das heute?“. Folgen Sie einem Link, wenn die Antwort ja lautet.

In der Praxis besteht eine gesunde Mehrheit des realen UML aus vieren davon: Klasse, Sequenz, Anwendungsfall und Aktivität. Die anderen zehn existieren, weil jemand sie brauchte, und drei oder vier davon sind wirklich hervorragend, wenn die Lage es verlangt - ein Zustandsautomat für einen Lebenszyklus, ein Verteilungsdiagramm für ein Infrastruktur-Review. Den Rest können Sie lesen, wenn Sie ihm begegnen, und nie zeichnen.

Gehen Sie von der Frage aus, nicht vom Diagramm. Der Fehler ist, zuerst einen Diagrammtyp zu wählen und dann zu entscheiden, was darauf soll - so landet man bei einem Klassendiagramm mit zweihundert Kästen, das nie jemand gelesen hat.

• „Wer nutzt das und wofür?“ - Anwendungsfalldiagramm. Umfang und Akteure, bevor es einen Entwurf gibt.
• „Was sind die Begriffe und wie hängen sie zusammen?“ - Klassendiagramm. Die Standard-Strukturansicht.
• „Was passiert, wenn jemand auf Bezahlen klickt?“ - Sequenzdiagramm. Reihenfolge der Nachrichten zwischen Beteiligten.
• „Wie sieht der Prozess aus, samt Verzweigungen?“ - Aktivitätsdiagramm. Fluss mit Entscheidungen und Parallelität.
• „In welchen Zuständen kann dieses Ding sein?“ - Zustandsdiagramm. Lebenszyklus und erlaubte Übergänge.
• „Was läuft wo?“ - Verteilungsdiagramm. Knoten, Artefakte, Umgebungen.
• „Was sind die Dienste und ihre Verträge?“ - Komponentendiagramm. Angebotene und benötigte Schnittstellen.
• „Wie ist die Codebasis organisiert?“ - Paketdiagramm. Gruppierung und erlaubte Abhängigkeiten.

Es ist kein Prozess. UML sagt nichts darüber, wann man modelliert, wie viel man modelliert oder wer es abnimmt. Es ist eine Notation. Methoden wie RUP wurden darum herum gebaut und werden häufig damit verwechselt; Sie können UML in jedem Prozess einsetzen, auch in gar keinem.

Es ist keine Programmiersprache. UML-Modelle können detailliert genug sein, um Code zu erzeugen, und manche Werkzeuge tun genau das. Die meisten Teams tun es nicht und sollten es nicht. Vollständige Round-Trip-Codegenerierung ist der mit Abstand häufigste Grund, an dem UML-Vorhaben scheitern: Das Modell wird zu einer zweiten, schlechteren Kopie des Quellcodes, die niemand aktualisiert.

Es ist kein Alles-oder-nichts. Es gibt keine Pflicht, alle vierzehn Diagramme zu benutzen oder jede Klasse zu modellieren. Ein einziges Sequenzdiagramm zu zeichnen, um einen Streit darüber zu klären, wer wen aufruft, ist ein völlig legitimer Einsatz von UML und wahrscheinlich sein wertvollster.

Es ist nicht dasselbe wie ArchiMate. Beide sind Modellierungssprachen und überschneiden sich genug, um zu verwirren. UML modelliert Software - Klassen, Komponenten, Nachrichten. ArchiMate modelliert das Unternehmen darum herum - Geschäftsprozesse, Fähigkeiten, Anwendungs- und Technologieschichten. Eine grosse Organisation braucht typischerweise beides, auf verschiedenen Flughöhen.

Die ehrliche Antwort lautet: viel weniger, als die Werkzeuge nahelegen. Ein Modell verdient seinen Platz, wenn es öfter gelesen als bearbeitet wird. Drei Dinge bewirken das zuverlässig.

Modellieren Sie die Teile, die man schwer im Kopf behält. Der Zahlungs-Zustandsautomat mit neun Zuständen und zwei unzulässigen Übergängen ist ein Diagramm wert. Das DTO mit drei Feldern nicht.

Modellieren Sie pro Diagramm auf einer Flughöhe. Das häufigste Versagen eines echten Klassendiagramms ist, Domänenbegriffe und Framework-Installation auf dieselbe Fläche zu mischen. Zwei Diagramme, jedes in sich stimmig, schlagen eines, das technisch vollständig ist.

Modellieren Sie, was Sie behalten werden. Ein Diagramm in einem Foliensatz ist eine Zeichnung mit der Haltbarkeit einer Sitzung, und das ist in Ordnung, solange Sie wissen, dass es das ist. Ein Diagramm im Repository, neben dem Code, den es beschreibt, ist ein Modell - und es braucht jemanden, der es verantwortet.

Wenn die Notation neu für Sie ist, lesen Sie zuerst den Artikel zum Klassendiagramm. Es trägt den grössten Teil des UML-Vokabulars - Generalisierung, Assoziation, Multiplizität, Komposition - und jedes andere Strukturdiagramm übernimmt diese Zeichen. Lesen Sie dann den Artikel zum Sequenzdiagramm, der dasselbe für das Verhalten leistet.

Diese beiden decken das meiste ab, was Sie je zu lesen bekommen. Alles Übrige in dieser Reihe ist so geschrieben, dass man es an dem Tag aufgreifen kann, an dem man es braucht, in beliebiger Reihenfolge, und jeder Artikel setzt nur diese beiden voraus.