3.3 Die 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 des UML-Diagramms lassen sich die Attribute ablesen, im zweiten die Methoden. Das + vor den Eigenschaften zeigt an, dass sie öffentlich sind und jeder sie nutzen kann. Die Typenangabe ist gegenüber Java umgekehrt: Zuerst kommt der Name der Variable, dann der Typ beziehungsweise bei Methoden der Typ des Rückgabewerts.
 Hier klicken, um das Bild zu Vergrößern
Abbildung 3.1
Die Klasse java.awt.Point in der UML-Darstellung
3.3.1 Hintergrund und Geschichte zur UML
 
Die UML ist mehr als nur eine Notation zur Darstellung von Klassen. Mit ihrer Hilfe lassen sich die Analyse und das 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 war die erste Veröffentlichung im Jahre 1995. Die Initiatoren waren Jim Rumbaugh und Grady Booch. Später trat 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 folgende Tabelle gibt eine Kurzübersicht über die Veränderungen der UML:
1994
|
Booch und Rumbaugh vereinigen ihre Ansätze OOAD und OMT.
|
1995
|
Unified Method in der Version 0.8. Jacobson bringt OOSE mit ein, die UML wird vereinfacht, von einer einheitlichen Methode wird abgesehen.
|
1996
|
Die UML in der Version 0.9. Notation wird verfeinert, unter anderem von vielen Unternehmen wie Oracle, Microsoft, Digital und HP.
|
1997
|
Versionen 1.0 und 1.1 erscheinen. Die UML wird bei der OMG eingereicht. Im September wird die UML 1.1 zum Standard.
|
1998
|
Version 1.2 mit Detailverbesserungen und einigen Korrekturen
|
1999
|
Die UML in der Version 1.3
|
2000
|
UML 1.4
|
2004
|
UML 2.0. Augenmerk auf XML Metadata Interchange (XMI), Model Driven Architecture (MDA), Geschäftsprozessmodellierung (BPM) und Unterstützung von Echtzeitmodellierung (RT) durch neue Diagrammtypen
|
Eine aktuelle Version des Standards lässt sich unter java-tutor.com/go/uml beziehen.
3.3.2 Wichtige Diagrammtypen der UML
 
In der UML werden unterschiedliche Diagramme definiert, die die unterschiedlichen Sichten auf die Software beschreiben. Für die einzelnen Phasen im Softwareentwurf sind unterschiedliche Diagrammtypen wichtig. Wir wollen kurz drei Diagramme und ihr Einsatzgebiet besprechen.
Use Cases
Die Use-Cases-Diagramme entstehen meist während der Anforderungsphase und beschreiben die Geschäftsprozesse, indem die Interaktion von Personen oder von bereits existierenden Programmen mit dem System dargestellt werden. Die handelnden Personen oder aktiven Systeme werden Aktoren genannt. Ein Use Case beschreibt dann eine Interaktion mit dem System. Dazu werden die Aktoren als Männchen gemalt (wobei die Geschlechter nicht zu erkennen sind) und die einzelnen Anwendungsfälle (Use Cases) als Ellipsen.
Klassendiagramme
Für die statische Sicht auf einen Programmentwurf sind Klassendiagramme einer der wichtigsten Diagrammtypen. Sie sind besonders interessant, da Hilfsprogramme aus diesen Diagrammen automatisch Teile des Quellcodes erzeugen können. Die Diagramme stellen zum einen die Elemente der Klasse dar, zum anderen die Beziehungen der Klassen untereinander. Die Diagramme werden in diesem Buch häufiger eingesetzt. Klassen werden als Rechteck dargestellt und die Beziehungen zwischen den Klassen durch Linien angedeutet.
Interaktionsdiagramme
Der Begriff umfasst zwei Unterdiagramme zur Darstellung der zeitlichen Abläufe eines Systems: die Sequenzdiagramme und die Kollaborationsdiagramme. Damit wird im Gegensatz zum Klassendiagramm das dynamische Verhalten von Objekten dargestellt.
|