3.3    Natürlich modellieren mit der UML (Unified Modeling Language) * 

Für die Darstellung einer Klasse lässt sich Programmcode verwenden, also eine Textform, oder aber eine grafische Notation. Eine dieser grafischen Beschreibungsformen ist die UML. Grafische Abbildungen sind für Menschen deutlich besser zu verstehen und erhöhen die Übersicht.

Im ersten Abschnitt eines UML-Diagramms lassen sich die Attribute ablesen, im zweiten die Operationen. Das + vor den Eigenschaften (siehe Abbildung 3.1) zeigt an, dass sie öffentlich sind und jeder sie nutzen kann. Die Typangabe ist gegenüber Java umgekehrt: Zuerst kommt der Name der Variablen, dann der Typ bzw. bei Methoden der Typ des Rückgabewerts.

Abbildung 3.1    Die Klasse »java.awt.Point« in der UML-Darstellung

 

3.3.1    Hintergrund und Geschichte der UML * 

Die UML ist mehr als eine Notation zur Darstellung von Klassen. Mit ihrer Hilfe lassen sich Analyse und Design im Softwareentwicklungsprozess beschreiben. Mittlerweile hat sich die UML jedoch zu einer allgemeinen Notation für andere Beschreibungen entwickelt, zum Beispiel für Datenbanken oder Workflow-Anwendungen.

Vor der UML waren andere Darstellungsvarianten wie OMT oder Booch verbreitet. Diese waren eng mit einer Methode verbunden, die einen Entwicklungsprozess und ein Vorgehensmodell beschrieb. Methoden versuchen, eine Vorgehensweise beim Entwurf von Systemen zu beschreiben, etwa »erst Vererbung einsetzen und dann die Attribute finden« oder »erst die Attribute finden und dann mit Vererbung verfeinern«. Bekannte OO-Methoden sind etwa Shlaer/Mellor, Coad/Yourdon, Booch, OMT und OOSE/Objectory.

Aus dem Wunsch heraus, OO-Methoden zusammenzufassen, entstand die UML – anfangs stand die Abkürzung noch für Unified Method. Die Urversion 0.8 wurde im Jahre 1995 veröffentlicht. Die Initiatoren waren Jim Rumbaugh und Grady Booch. Später kam Ivar Jacobson dazu, und die drei »Amigos« erweiterten die UML, die in der Version 1.0 bei der Object Management Group (OMG) als Standardisierungsvorschlag eingereicht wurde. Die Amigos nannten die UML nun Unified Modeling Language, was deutlich macht, dass die UML keine Methode ist, sondern lediglich eine Modellierungssprache. Die Spezifikation erweitert sich ständig mit dem Aufkommen neuer Softwaretechniken, und so bildet die UML 2.0 Konzepte wie Model-Driven Architecture (MDA) und Geschäftsprozessmodellierung (engl. Business Process Modeling, kurz BPM) ab und unterstützt Echtzeitmodellierung durch spezielle Diagrammtypen. Eine aktuelle Version des Standards lässt sich unter http://tutego.de/go/uml einsehen.

 

3.3.2    Wichtige Diagrammtypen der UML * 

Die UML definiert diverse Diagrammtypen, die unterschiedliche Sichten auf die Software beschreiben können. Für die einzelnen Phasen im Softwareentwurf sind jeweils andere Diagramme wichtig. Wir wollen kurz vier Diagramme und ihr Einsatzgebiet besprechen.

Anwendungsfalldiagramm

Ein Anwendungsfalldiagramm (Use-Cases-Diagramm) entsteht meist während der Anforderungsphase und beschreibt die Geschäftsprozesse, indem es die Interaktion von Personen – oder von bereits existierenden Programmen – mit dem System darstellt. Die handelnden Personen oder aktiven Systeme werden Aktoren genannt und sind im Diagramm als kleine (geschlechtslose) Männchen angedeutet. Anwendungsfälle (Use Cases) beschreiben dann eine Interaktion mit dem System.

Klassendiagramm

Für die statische Ansicht eines Programmentwurfs ist das Klassendiagramm einer der wichtigsten Diagrammtypen. Ein Klassendiagramm stellt zum einen die Elemente der Klasse dar, also die Attribute und Operationen, und zum anderen die Beziehungen der Klassen untereinander. Klassendiagramme werden in diesem Buch häufiger eingesetzt, um insbesondere die Assoziation und Vererbung zu anderen Klassen zu zeigen. Klassen werden in einem solchen Diagramm als Rechteck dargestellt, und die Beziehungen zwischen den Klassen werden durch Linien angedeutet.

Objektdiagramm

Ein Klassendiagramm und ein Objektdiagramm sind sich auf den ersten Blick sehr ähnlich. Der wesentliche Unterschied besteht darin, dass ein Objektdiagramm die Belegung der Attribute, also den Objektzustand, visualisiert. Dazu werden sogenannte Ausprägungsspezifikationen verwendet. Mit eingeschlossen sind die Beziehungen, die das Objekt zur Laufzeit mit anderen Objekten hält. Beschreibt zum Beispiel ein Klassendiagramm eine Person, so ist nur ein Rechteck im Diagramm. Hat diese Person zur Laufzeit Freunde (gibt es also Assoziationen zu anderen Personen-Objekten), so können sehr viele Personen in einem Objektdiagramm verbunden sein, während ein Klassendiagramm diese Ausprägung nicht darstellen kann.

Sequenzdiagramm

Das Sequenzdiagramm stellt das dynamische Verhalten von Objekten dar. So zeigt es an, in welcher Reihenfolge Operationen aufgerufen und wann neue Objekte erzeugt werden. Die einzelnen Objekte bekommen eine vertikale Lebenslinie, und horizontale Linien zwischen den Lebenslinien der Objekte beschreiben die Operationen oder Objekterzeugungen. Das Diagramm liest sich somit von oben nach unten.

Da das Klassendiagramm und das Objektdiagramm eher die Struktur einer Software beschreiben, heißen die Modelle auch Strukturdiagramme (neben Paketdiagrammen, Komponentendiagrammen, Kompositionsstrukturdiagrammen und Verteilungsdiagrammen). Ein Anwendungsfalldiagramm und ein Sequenzdiagramm zeigen eher das dynamische Verhalten und werden Verhaltensdiagramme genannt. Weitere Verhaltensdiagramme sind das Zustandsdiagramm, das Aktivitätsdiagramm, das Interaktionsübersichtsdiagramm, das Kommunikationsdiagramm und das Zeitverlaufsdiagramm. In der UML ist es aber wichtig, die zentralen Aussagen des Systems in einem Diagramm festzuhalten, sodass sich problemlos Diagrammtypen mischen lassen.

 

3.3.3    UML-Werkzeuge * 

In der Softwareentwicklung gibt es nicht nur den Java-Compiler und die Laufzeitumgebung, sondern viele weitere Tools. Eine Kategorie von Produkten bilden Modellierungswerkzeuge, die bei der Abbildung einer Realwelt auf die Softwarewelt helfen. Insbesondere geht es um Software, die alle Phasen im Entwicklungsprozess abbildet.

Mit UML-Werkzeugen können Software-Architekten und Entwickler das Design einer Software besser im Blick halten. Mit ihm lassen sich die UML-Diagramme zeichnen und verändern. Im nächsten Schritt kann ein gutes UML-Tool aus diesen Zeichnungen Java-Code erzeugen. Noch weiter als eine einfache Codeerzeugung gehen Werkzeuge, die aus Java-Code umgekehrt UML-Diagramme generieren. Diese Reverse-Engineering-Tools haben jedoch eine schwere Aufgabe, da Java-Quellcode semantisch so reichhaltig ist, dass entweder das UML-Diagramm »zu voll« ist, völlig unzureichend formatiert ist oder Dinge nicht kompakt abgebildet werden. Die Königsdisziplin der UML-Tools bildet das Roundtrip-Engineering. Im Optimalfall sind dann das UML-Diagramm und der Quellcode synchron, und jede Änderung der einen Seite spiegelt sich sofort in einer Änderung auf der anderen Seite wider.

Hier eine Auswahl von Produkten:

• Enterprise Architect (http://www.sparxsystems.de) ist ein Produkt von Sparx Systems. Es unterstützt UML 2.5 und bietet umfangreiche Modellierungsmöglichkeiten. Für die Business & Software Engineering Edition Standard License sind 599 USD fällig. Eine 30-tägige Testversion ist frei. Das Tool ist an sich eine eigenständige Software, die Integration in Eclipse (und MS Visual Studio) ist möglich.

• MyEclipse (http://www.genuitec.com/products/myeclipse) von Genuitec besteht aus einer großen Sammlung von Eclipse-Plugins, unter anderem mit einem UML-Werkzeug. Einblick in das kommerzielle Werkzeug bekommen Sie hier: http://www.genuitec.com/products/myeclipse/learning-center/uml/myeclipse-uml2-development-overview.

• ObjectAid UML Explorer for Eclipse (http://www.objectaid.com) ist ein kleines und kompaktes Werkzeug, das Klassen aus Eclipse einfach visualisiert. Es entwickelt sich langsam zu einem größeren kommerziellen Produkt. Die UML-Diagramme aus dem Buch sind in der Mehrzahl mit ObjectAid generiert.

• Together (http://www.microfocus.com/de-de/products/requirements-management/together) ist ein alter Hase unter den UML-Tools – mittlerweile ist der Hersteller Borland bei Micro Focus gelandet. Es gibt eine 30-tägige Demoversion. Die letzte Version 12.9 unterstützt Java 8 und basiert auf Eclipse 4.6.1, ist also schon angestaubt.

• Rational Rose (http://www-03.ibm.com/software/products/de/enterprise) ist das professionelle UML-Werkzeug von IBM. Es zeichnet sich durch seinen Preis aus, aber auch durch die Integration einer ganzen Reihe weiterer Werkzeuge, etwa für Anforderungsdokumente und Tests.

• UMLet (http://www.umlet.com) ist ein UML-Zeichenwerkzeug und geht auf ein Projekt der Vienna University of Technology zurück. Es kann alleinstehend eingesetzt oder in Eclipse eingebettet werden. Auf GitHub liegt der offene Quellcode unter http://github.com/umlet/umlet. Die neue Version http://www.umletino.com funktioniert auch im Browser.

• Der quelloffene UML Designer (http://obeonetwork.github.io/UML-Designer) greift auf viele Eclipse-Projekte zurück.

• UML Lab von yatta (http://www.uml-lab.com/de/uml-lab) ist ein Eclipse-basiertes Werkzeug mit Round-Trip-Engineering. Es kostet ab 199 EUR, und es gibt eine Demo-Version zum Testen.

Viele Werkzeuge kamen und gingen. Unter ihnen waren:

• ArgoUML (http://argouml.tigris.org), ein freies UML-Werkzeug mit UML-1.4-Notation auf der Basis von NetBeans. Es ist eigenständig und nicht in Eclipse integriert – Ende 2011 stoppte die Entwicklung; die letzte Version ist 0.34.

• TOPCASED/PolarSys (http://www.topcased.org) war ein umfangreicher UML-Editor für Eclipse. Nachfolger ist Papyrus.