UML 2.0: Evolution oder Degeneration?

Mario Jeckle, Chris Rupp, Jürgen Hahn, Barbara Zenger und Stefan Queins
Erschienen in der Ausgabe Mai/Juni (3/2004), Seiten 12-19, der Zeitschrift Objekt Spektrum

Der UML-Standard in der Version 2 steht kurz vor seiner Verabschiedung durch die OMG. Damit entsteht eine vollständig überarbeitete UML mit neuen Diagrammen, Modellierungselementen und einem deutlich gestrafften Metamodell. Die Sprache wurde semantisch präzisiert und die Diagramme sind näher an die Ausführbarkeit gerückt. Hierbei wurde insbesondere in die Verhaltensdiagramme viel Arbeit investiert. Der Artikel verschafft Ihnen einen Überblick über die erfolgten Änderungen und diskutiert die Frage, ob und für wen sich ein Umstieg auf die UML 2 lohnt.

Die UML ist heute das Mittel der Wahl, wenn es darum geht, Softwaresystem zu analysieren und zu entwerfen. In vergleichsweise kurzer Zeit hat sie sich vom kleinsten gemeinsamen Nenner dreier Notationen (1996: UML 0.9 von Booch, Rumbaugh, Jacobson) zum De-facto-Standard entwickelt. Ist die UML (1.x) so gut, oder waren die Konkurrenznotationen einfach nur so unbrauchbar? Und wenn die UML so gut ist, wieso benötigen wir dann mit UML 2.0 eine neue, völlig überarbeitete Version?

Nach langer Kontinuität des durch die Object Management Group (OMG) betriebenen Standardisierungsprozesses, der als Ergebnis der Kärrnerarbeit nahezu alljährlich evolutionäre Punktversionen der UML produzierte, unternimmt das Industriegremium mit der fast abgeschlossenen Fassung der UML 2.0 einen zentralen Versionssprung. Hielten sich die Unterschiede zwischen den jeweiligen Vorgängern in vergleichsweise eng umrissenen überschaubaren Grenzen und waren zumeist lediglich für Spezialanwender des direkt modifizierten Konstrukts, Berater sowie Werkzeug- und Methodenautoren von Interesse, so enthält Version zwei der UML eine Reihe von Neuerungen, die auch für den Praktiker sowie gleichermaßen für Architekten und Software-Entwickler relevant sind.

Insgesamt betrachtet versucht UML 2.0 die in den vergangenen rund fünf Jahren Breiteneinsatz der Sprache gewonnenen Anwendungserfahrungen der Modellierer gesammelt aufzugreifen und damit gleichzeitig den inzwischen erhobenen Erweiterungswünsche Rechnung zu tragen. UML 2.0 bildet damit, bereits im grundlegenden Ansatz eine neue Version der Modellierungssprache, die sich deutlich von revisionierenden Änderungen der verschiedenen Ausprägungen der ersten Standardgeneration abhebt.

Im Detail trachtet die Neufassung danach Änderungen an drei zentralen Punkten der Sprachstruktur einzuführen. So soll gleichzeitig die semantische Präzision der angebotenen graphischen Primitive gesteigert werden, die angebotenen Diagrammtypen (siehe Abbildung 1) so ergänzt werden, dass ihre direkte Ausführbarkeit in greifbare Nähe rückt und dennoch die Übersichtlichkeit der Spezifikation und damit der Modellierungssprache selbst gesteigert werden.

Abbildung 1Die Diagtypen der UML 2.0
Die Diagtypen der UML 2.0
(click on image to enlarge!)

Die unnötige Komplexität der UML-1.x Versionen und des sie beschreibenden normativen Dokuments stellt zweifelsfrei die häufigst geäußerte Kritik der Anwendergemeinde dar, betrifft sie doch direkt den Modellierer, da sie dem schnellen Erlernen der UML sowie ihrer effektiven Nutzung in der Praxis im Wege steht. Um diesem Komplexitätsübelstand abzuhelfen fällt die Neufassung, trotz des nachfolgend beschriebenen Mächtigkeitszuwachses, quantitativ deutlich schlanker als ihre Vorgänger aus. Dies konnte durch vielfache Abstraktion der angebotenen Konzepte und Wiederverwendung der so entstehenden verallgemeinerten Definitionen erfolgen. Eines dieser Konzepte (und das zentrale Konzept in der UML überhaupt) ist das des Classifiers, welches das objektorientierte Grundkonzept der Klasse weiter abstrahiert. Ein Classifier ist kein Modellierungselement, sondern ein gedankliches Konstrukt mit gewissen Eigenschaften zur Klassifizierung. Beispiele für Classifier sind Use Case, Zustandsautomat, Akteur und die Klasse selbst. Anzumerken ist jedoch, dass dieser durch Abstraktion erreichte quantitative Gewinn an Übersichtlichkeit durch einen Verlust an intuitiver Zugänglichkeit erkauft wird und sich die offiziellen UML 2.0-Dokumente der OMG schlechterdings kaum für den Einstieg in die Modellierungssprache eignen.

Jenseits der erhobenen Anwenderforderungen birgt auch der Markt einige Gründe für die grundlegende Überarbeitung der UML. Im Zeitraum seit der UML-Ur-Definition hat sich das Softwareentwicklungsumfeld gravierend verändert. So verdrängten neu aufgekommene Programmiersprachen (hier ist „noch“ Java und „noch nicht“ C# gemeint, dies wird sich vielleicht mit UML 3.0 ändern ;-) die bis dato Vorherrschenden, auch neue Anwendungsparadigmen -- wie Application-Server-basierte Lösungen - haben breite Bedeutung erlangt. Überdies dringen objektorientierte Techniken mit dem Erschließen des Marktes eingebetteter (Realzeit-)Systeme in Anwendungsdomänen vor, die bisher „klassischen“ Ansätzen vorbehalten waren.

Ferner wird die Notwendigkeit einer Überarbeitung der UML schon allein durch den an der Modellierungssprache immer stärker zu Tage tretenden Second System Effect [Bro75] offenkundig. Dieser klassische Defekt vieler Systeme, die als Verbesserung eines bestehenden Vorgängers konzipiert wurden, macht auch vor UML, welche ursprünglich als erweiterte Vereinigung der Notationen nach Rumbaugh et al. (OMT), Booch (die mit den Wolken) und Jacobson das Licht der Welt erblickte, nicht halt. Die UML 1.x versucht viele Details gegenüber ihren Vorgängeransätzen zu verbessern und verliert sich daher leider an vielen Stellen in „Featuritis“.
Programmiersprachenspezifische Sprachkonstrukte wie C++s altbekanntes friend oder die höchst unterschiedlich interpretierte Semantik der Aggregations- und Kompositionsassoziationen illustrieren nur zwei der vielzahligen Fälle.

Die Entfernung -- oder ihre zumindest erfolgte Verschiebung in optionale Sprachanteile, welche bestimmten Anwendungsfällen vorbehalten sind -- der angesprochen programmiersprachenspezifischen Sprachkonstrukte aus der UML markiert gleichzeitig auch den durch die Model Driven Architecture-Initiative der OMG verstärkten Trend der UML-Nutzung als plattformunabhängige logische Modellierungssprache.

back to top   Die Zeiten ändern sich ...

 

Um UML 2.0 nicht in dieselbe Falle vermeintlicher Verbesserungen tappen zu lassen, wurde dem süßen Gift radikaler Änderungen widerstanden und stattdessen die Hand (manches Mal auch die Axt) eher an die Wurzel der Sprache gelegt als an ihre, in den verschiedenen Diagrammtypen repräsentierten, sichtbaren Komponenten. Daher wurde die bereits in UML 1.x eingeführte bekannte Notation zur Formulierung statischer Modelle kaum angetastet. So präsentieren sich Klassen-, Objekt- und Verteilungsdiagramm in kaum veränderten Kleidern. Jedoch wurden ihre Interna, durch ein nahezu vollständig neu gefasstes Metamodell (d.h. die in UML erfolgte Beschreibung der UML) auf eine stabilere Basis gestellt, die zusätzlich die Bedeutung der einzelnen Modellkonstrukte durch formale Semantikbeschreibungen präzisiert. Für den Sprachanwender offenbart sich dies als doppelter Gewinn. Einerseits konsolidiert das neue Metamodell identische Konzepte durch Verwendung derselben Metaelemente und fällt daher deutlich kompakter aus als sein schwerfälliger (und sich leider gern widersprüchlich gebender) Vorgänger. Aus diesem Grunde kann UML 2.0 leichter erlernt und angewendet werden, da die vorhandenen Basiskonzepte in verschiedenen Diagrammen mit demselben Verhalten und identischer Bedeutung eingesetzt werden können. Zum anderen vereinfacht die neue Sprachbeschreibung die Werkzeug- und Methodenentwicklung, die besonders unter bestehenden Widersprüchen und semantischen Unzulänglichkeiten litten.

Mit dem Kompositionsstrukturdiagramm wurde jedoch ein zusätzlicher Diagrammtyp in die UML aufgenommen, der besser als bisher die Abbildung vollständiger Architekturen -- daher wird dieses Diagramm auch oftmals schlicht als Architekturdiagramm bezeichnet -- unterstützen soll. Der neue Diagrammtyp zielt auf die Top-Down-Modellierung vollständiger Systeme auf einem geringeren Detaillierungsniveau als es die implementierungsnahen Konstrukte des Klassendiagramms oder die abstrahierten des Verteilungsdiagramms gestatten.

Nachhaltigste Änderungen erfährt indes der Teilbereich der dynamischen Modellierung. Er wurde grundlegend entkernt und renoviert, sodass er sich zwar noch der aus den Vorgängerversionen bekannten graphischen Modellelementen bedient, diese jedoch überwiegend mit neuer Bedeutung und Mächtigkeit anbietet.

back to top    Die UML 2.0 Verhaltensdiagramme

 

Das Gros der Standardisierungsarbeit an der UML 2.0 ist in die Verhaltensdiagramme geflossen. Das verwundert die Kenner der UML 1.x mit Sicherheit nicht. Zu groß waren die semantischen Mängel, zu eingeschränkt oder unhandlich die Notationsmittel und zu schwach die Anbindung an die statischen Diagramme. Wie auch sonst hätten sich Alternativen von ARIS bis zur SDL behaupten können, sogar das über 30 Jahre alte Nassi-Shneiderman-Struktogramm hatte ohne wenn und aber seine Berechtigung. Den Anspruch eine universelle Sprache für die meisten Bereiche der Software- und Systementwicklung zu sein, wurde die UML in der Dynamikmodellierung bisher am wenigsten gerecht.

Konzepte statt Diagramme

Nun, mit der UML 2.0 sollte und wird alles anders. Selbstverständlich kann der vorliegende Artikels nur einen Bruchteil von dem vermitteln, was sich wirklich getan hat, jedoch sollen die wichtigsten Neuerungen aufgezeigt werden. Dabei erweist sich die in UML verwirklichte Trennung zwischen abstrakt definierten Grundkonzepten einerseits und den sie graphisch visualisierenden Notationselementen andererseits, als sehr hilfreich.

Die UML 2.0 bleibt jedoch eine reine graphisch definierte Notation; sie ist weder formal definiert, noch berücksichtigt sie prozessule Aspekte der Modellerstellung. Die Basiskonzepte legen die Semantik fest, auf welche Diagramme und Notationselemente als Sichten und Filter einwirken. Dieselben Sachverhalte (besser: dieselben Konzepte) werden in verschiedenen Diagrammtypen unterschiedlich dargestellt oder genutzt. Der Vorteil für Sie: es genügt, wenige Konzepte zu erlernen, die konkrete Notation können Sie dann in UML 2 glasklar oder in der einschlägigen Literatur nachlesen. So wissen Sie zum Beispiel nach dem Lesen dieses Artikels, dass die Verhaltensdiagramme schachtelbar sind. Und zwar alle sieben, vom Use-Case- bis zum Sequenzdiagramm. Zwar alle mit einer variierenden Notation, aber mit einem durchgängigen Konzept.

Es ist durchaus möglich und sogar im Standard vorgesehen, dass die UML in den nächsten Jahren noch um weitere Diagrammtypen, sprich Sichten, erweitert wird -- es ist jedoch die Zielsetzung die Konzepte dabei stabil zu halten. Natürlich fokussiert ein Diagramm immer einen bestimmten Aspekt und nicht in allen Diagrammen werden alle Konzepte unterstützt, dennoch besticht die UML 2.0 durch ihre Einheitlichkeit und Konformität in ihrer Anwendung.

Aus diesem Grund unterbleibt an dieser Stelle die Einführung der weit über 100 neuen Notationselemente im dynamischen Bereich im einzelnen, zugunsten der Darstellung und Demonstration einiger Basiskonzepte der Dynamiknotation.

Zerlegbarkeit und Verknüpfung von Verhalten

Zunächst ist es sicherlich kein Geheimnis, dass moderne Systeme häufig in ihrer Komplexität und Struktur enorm anwachsen und für einzelne Personen und Teams alleine nicht mehr handhabbar sind. Derartiges überträgt sich auch auf die zugehörigen UML-Modelle, die gerade in der Verhaltensbeschreibung im Detaillierungsgrad sehr schnell anwachsen. Als Beispiel hierfür können Aktivitäts- und Sequenzdiagramme angeführt werden, die neben dem Standardablauf einer Ausführung zusätzlich Fehler- und Sonderfälle berücksichtigen können oder Situationen an denen sehr viele Objekte beteiligt sind. Unabhängig davon ob die Systemmodellierung Bottom-Up oder Top-Down erfolgt, ab einer gewissen Größe kann der Überblick nur durch Einführung verschiedener Abstraktionsebenen gewährleistet werden, zu unterschiedlich sind die Anforderungen der verschiedenen Projektbeteiligten. Architekten und Analytiker benötigen einen Grobüberblick, Feindesigner modellieren Details und für einen Codegenerierungsansatz ist in aller Regel ein hoher Präzisionsgrad nötig.

In der UML 2.0 dürfen daher Verhaltensdiagramme beliebig durch Schachtelung verfeinert oder vergröbert werden. Es ist zudem möglich, gleichartiges, mehrmals beschriebenes Verhalten an nur genau einer Stelle zu definieren und an beliebigen anderen Stellen einzubinden.

Derartige Zerlegungen von Verhaltensbeschreibungen erfordern leistungsfähige Mechanismen zur Konsistenzwahrung. Die hierfür in UML 2.0 eingeführten Elemente werden nachfolgend dargestellt.

Rahmen und Verhaltensparameter
Um Diagramme oder darin beschriebenes Verhalten referenzieren zu können, muss dies klar umgrenzt und eindeutig identifizierbar sein. Hierzu gibt UML 2.0 Rahmen (siehe Abbildung 2), die Verhaltensbeschreibungen einen Namen geben und die Angabe von Ein- und Ausgabeparametern (in in der von Methodensignaturen gewohnten Weise) ermöglichen. Derart deklariertes Verhalten kann an anderer Stelle „aufgerufen“ werden. Dabei darf beispielsweise aus einem Aktivitätsdiagramm ein mit einem Automaten beschriebenes Verhalten referenzier werden. Darüberhinaus sind ab UML 2.0 bei allen Verhaltensaufrufen die Vor- und Nachbedingungen explizit notierbar.

Während die Schachtelung bei Use Cases und Aktivitäten bisher üblich war, wurde sie im Bereich der Zustandsautomaten und Interaktionsmodellierung (Sequenzdiagramme, ...) verfeinert und neu eingeführt. Mittels Unterzustandsautomatenzuständen und Interaktionsreferenzen lassen sich Automaten bzw. Interaktionen auslagern, zudem dürfen in Sequenzdiagrammen die Lebenslinien zerlegt werden. Dies ist insbesondere dann sinnvoll, wenn die Lebenslinie z. B. eine Klasse oder Komponente mit einer komplexen internen Struktur repräsentiert. Zur Darstellung der internen Kommunikationsabläufe (white-box-Ebene) ist ein Zoom von der black-box-Ebene dann möglich (siehe Abbildung 2). Damit dürften ausufernde Sequenzdiagramme der Vergangenheit angehören.

Verknüpfungspunkte
Neben den Verhaltensparametern der Rahmen lassen sich Verhaltenbeschreibungen über spezielle benannte Schnittstellenpunkte miteinander verknüpfen. So dienen Gates der Verbindung von Interaktionsdiagrammen (siehe Abbildung 2) und Ein- und Austrittspunkten für Unterzustands-Automatenzustände (siehe Abbildung 5).

Abbildung 2Die Neuerungen des Sequenzdiagramms
Die Neuerungen des Sequenzdiagramms
(click on image to enlarge!)

Interaktionsübersichtsdiagramm
Zur Unterstützung eines Top-Down-Vorgehens wurde zudem mit dem Interaktionsübersichtsdiagramm (siehe Abbildung 1), ein neuer Diagrammtyp eingeführt. Er fädelt unterschiedliche Interaktionsdiagramme (Sequenz-, Timing-, Kommunikationsdiagramme) zusammen. Es ist von seinem Wesen her ein Aktivitätsdiagramm, dass statt Aktionen (Ablaufschritte) Interaktionsdiagramme enthält.

Statt der Ausführung einer Aktion wird vollständiges Interaktionsdiagramm abgearbeitet. Dadurch wird die Möglichkeit geschaffen, den groben Ablauf in Form einer Aktivität zu modellieren, und die einzelnen Schritte als Interaktionen zu verfeinern. Nebenbei verknüpft das Modell die erstellten Interaktionsdiagramme. Ein solches Verhalten war in der Vorgängersprachversion nur per Namenskonvention möglich war.

back to top   Ausführbarkeit und semantische Präzision

 

Um es vorwegzunehmen, auch die UML 2.0 ist nicht ausführbar, es fehlt nach wie vor eine zugrunde liegende formale Grammatik und eindeutige Semantikbeschreibung.

Tokenkonzept für Aktivitätsdiagramme Den Aktivitätsdiagrammen liegt seit UML 2.0 eine aus den Petrinetzen entlehnte Tokensemantik (Abb. Abbildung 3) zugrunde, mit der präzise Regeln für die Ablauffluss, inklusive Parallelisierung, Zusammenführung, Threading und Objektfluss geschaffen werden. Damit hat sich das Aktivitätsdiagramm endgültig vom Zustandsautomaten emanzipiert. (Bei letzterem hat sich im Übrigen wenig an Semantik und Notation gegenüber der Vorgängerversion verändert. Sie beruhen immer noch auf den State Charts nach Harel  [Har87].) Ein Token entspricht dabei genau einem Ablaufthread, der erzeugt und vernichtet werden kann. Dabei repräsentiert das Token entweder das Fortschreiten des Ablauf- oder des Datenflusses. Damit geschaffene Möglichkeiten werden insbesondere in der Geschäftsprozessmodellierung von Nutzen sein [Oes03].
Bedauerlicherweise hat es auch eine Änderung der Begrifflichkeiten gegeben: Ein UML 2.0 Aktivitätsdiagramm (das Zeichenblatt) zeigt nun Aktivitäten (die Verhaltensbeschreibung); eine Aktivität zeigt Aktionen (die Schritte eines Ablaufs). Die aus früheren UML Varianten bekannten Aktivitäten heißen also jetzt Aktionen und werden überdies noch mit dem gleichen Symbol wie Zustände (Rechteck mit runden Ecken) notiert (vgl. Abbildung 4)

Abbildung 3Das Token-Konzept in der UML 2.0
Das Token-Konzept in der UML 2.0
(click on image to enlarge!)

Ereignismengen in der Interaktionsmodellierung
Im Umfeld der Interaktionsdiagramme hat man die Konzepte der Message Sequence Charts (vgl. [ITU99]) übernommen. Diese verfügen unter anderem über ein präzises Ereignismodell, welches eine Nachricht mit zwei Ereignissen (einem Sende- und einem Empfangsereignis) in Beziehung setzt. Beide Ereignisse sind voneinander entkoppelt, um das Senden und Empfangen getrennt behandeln zu können. Ein Nachrichtensequenz in einer bestimmten zeitlichen Reihenfolge -- und nichts anderes zeigen Interaktionsdiagramme -- lässt sich somit als geordnete Menge von Ereignissen darstellen. Dem Modellierer wird dadurch die Möglichkeit eröffnet präzise festzulegen, wann und in welcher Reihenfolge eine Nachricht gesendet bzw. empfangen wird. Nachrichten (Operationsaufruf oder Signalübermittlung) bzw. die zugehörigen Ereignisse lassen sich ordnen, parallelisieren oder in Abhängigkeit setzen (vgl. Abbildung 2).

back to top   Kontrolle der dynamischen Abläufe

 

Komplexe dynamische Abläufe und Algorithmen laufen in aller Regeln nicht linear ab, sondern werden beeinflusst (gesteuert, gelenkt, kontrolliert, wiederholt oder abgebrochen) durch Bedingungen oder Zustände, äußere Faktoren wie Nutzereingaben oder Berechnungsergebnisse. Die UML 2.0 bietet dazu alle aus den höheren Programmiersprachen bekannten Primitive durch eigenständige Notationselemente an.
Im Einzelnen sind dies:

Zur Umsetzung dieser Konzepte wurden in Aktivitätsdiagrammen spezielle Strukturierte Knoten (Schleifenknoten/Entscheidungsknoten) (vgl. Abbildung 4) und Exception-Handler eingeführt. In Sequenzdiagrammen gibt zum selben Zwecke kombinierte Fragmente (vgl. Abbildung 2), die entsprechende Konzepte in der dort gebräuchlichen Notation abbilden.
Daneben finden sich an vielen Stellen der neuen UML-Fassung kleinere Ergänzungen, mit denen eine bessere Kontrolle und auch Darstellung der dynamischen Abläufe möglich ist. Beispielsweise dürfen Kanten in Aktivitätsdiagrammen gewichtet werden, um den Ablauf in Abhängigkeit von einer Menge (Anzahl der Tokens, Durchläufe, vorliegenden Objekte) zu steuern. Mengenverarbeitungsbereiche stellen zudem die sequenzielle, parallelisierte oder iterative Abarbeitung von Mengenstrukturen (Felder, Listen, sonstige geordnete und ungeordnete Containerstrukturen, ...) dar.

Abbildung 4Einige neue Möglichkeiten in der Aktivitätsmodellierung
Einige neue Möglichkeiten in der Aktivitätsmodellierung
(click on image to enlarge!)

back to top   Synchronisation mit den Strukturdiagrammen

 

Die Modellierung von Struktur und Verhalten eines Systems erfordert die Verbindung und Konsistenzwahrung zwischen den statischen und dynamischen Diagrammen. Die UML 2.0 bietet hierfür eine verbesserte Unterstützung. Zum einen wie bereits erwähnt durch Zerlegung und Abbildung auf strukturierte Classifier und zum anderen durch kleine aber wichtige Details.

Verknüpfung von statischen Elementen und Interaktionen
Dies wirkt sich vor allem in Sequenzdiagramm aus, mit denen sich jetzt auf einfache Art und Weise Operationen beschreiben lassen. Dazu dürfen die Elemente einer Operationssignatur (Übergabeparameter und Rückgabewert) als Lebenslinien modelliert werden. Auch die Notation von skalarenoder mehrwertigen Attributen als Lebenslinie ist definiert. Eine Abbildung von Teilen (Parts), Schnittstellen und Ports, sowie eine Selbstreferenz (self) ist möglich. Mit den oben erwähnten kombinierten Fragmenten lässt sich damit jeglicher Code-Algorithmus eineindeutig abbilden und die Konsistenz zwischen Operationssignatur und Attributen bleibt gewahrt.

Spezialisierung und Generalisierung
Einem Classifier wie einer Klasse kann Verhalten in Form eines Zustandsautomaten zugewiesen werden, da Classifier spezialisierbar und generalisierbar sind, muss sich dies jedoch auf die entsprechende Verhaltensbeschreibung übertragen werden. Dies ist im UML 2 Metamodell [Born] verankert. Alle Verhaltensbeschreibungen (Use Cases, Aktivitäten, Zustandsautomaten und Interaktionen) dürfen spezialisiert werden um das Verhalten von Classifiern kompakt(er) zu notieren.

Als Beispiel zeigt der obere Teil der Abbildung 5 einen Geldautomaten, dessen Zustand Betrag erfasst in einer spezialisierten Form vorliegt (unterer Teil der Abbildung 5). Gestrichtelte Zustände beschreiben vererbte Zustände, mit {final} deklariert Zustände sind nicht redefinierbar. Die Semantik dieser Spezialisierung lässt sich sehr einfach durch den resultierenden Automaten beschreiben. Dieser ist in Abbildung 6 dargestellt.

Abbildung 5Spezialisierung von Zuständen
Spezialisierung von Zuständen
(click on image to enlarge!)

Abbildung 6Der resultierende Automat aus Abbildung 6
Der resultierende Automat aus Abbildung 6
(click on image to enlarge!)

Mit der Einführung der Ports wurde es notwendig, auch deren Verhalten zu beschreiben. Dazu steht in der UML 2.0 eine spezielle Variante der Zustandsautomaten, die Protokollzustandsautomaten zur Verfügung. Sie erlauben es, die in den Ports verwendeten Protokolle, d. h. die korrekte Aufrufreihenfolge von Operationen eines Ports, zu beschreiben. Daher unterscheiden sich sich in einigen Details von den reinen Zustandsautomaten. So dürfen sie an den Transitionen Vor- und Nachbedingungen enthalten, die vor bzw. nach der Ausführung der an der Transition angetragenen Operation gelten müssen. Die Zustände dienen als Gedächtnis, um sich den Fortschritt im Ablauf des Protokolls zu speichern.

back to top   Die Zeit als integrales UML 2.0-Konzept

 

Mit der Aufnahme des Zeitbegriffs als integraler Bestandteil des Sprachumfangs erschließen sich der UML 2.0 völlig neue Anwendungsbereiche, beispielsweise den Entwurf engebetteter Systeme, die Zeitanforderungen an als entscheidende Randbedingung berücksichtigen müssen. War es in UML 1.x nur möglich, die rein funktionalen Aspekte von Systemen dieses Typs zu beschreiben, so wird UML durch die in Version 2.0 eingführten Erweiterungen, nun auch bei den Analytikern und Designern solcher Systeme mit Sicherheit eine größere Akzeptanz finden.

Im Detail bedeutet die Berücksichtigung des „Faktors Zeit“, dass es nun möglich ist, eine Aktion oder ein Ereignis mit einer Zeit oder einer Zeitdauer zu notieren. Während in den UML 1.x-Versionen diese Annotationen noch recht stiefmütterlich neben den definierten Notationselementen standen, sind nun, nicht zuletzt durch das Zusammenwachsen der einzelnen Diagrammtypen, die Zusammenhänge präziser definiert.

Als Beispiel zeigt Abbildung 7 ein Sequenzdiagramm, das den Ablauf einer Alkoholkontrolle (ohne auf das Ergebnis näher einzugehen) modelliert. Zum Zeitpunkt t1 beginnt die Aktion messen. Dieser Zeitpunkt wird als Referenzzeitpunkt für das weitere Diagramm herangezogen und mit dem Schlüsselwort now bezeichnet. Nach 30 Sekunden ist die Messung beendet und die Berechnung des Ergebnisses kann beginnen. Nach weiteren 10 Sekunden steht das Ergebnis fest und wird dem Polizisten mitgeteilt.

Abbildung 730 Sekunden pusten ...
30 Sekunden pusten ...
(click on image to enlarge!)

Timing-Diagramm

Im Timing-Diagramm manifestiert sich eine weitere der Neuerung in der UML 2.0: Es stellt das zeitliche Verhalten eines Classifiers in den Vordergrund. Das bedeutet, Zustandsändeurngen und die dafür benötigte Zeit können mithilfe dieses Diagrammtyps ausgedrückt werden.
Bei der Definition des Timing-Diagramms wurden einige Anleihen bei aus der Elektrotechnik, in der diese Beschreibungsform bereits gängig ist, vorgenommen Das Diagramm stellt einzelne Classifier (in Abbildung 8 der Fahrer, der Polizist und der Alkomat), ihre verschiedenen Zustände und die Kommunikation zwischen ihnen dargestellt. Die Zeit ist auf der horizontalen Achse angetragen.

back to top   Verbesserter Umgang mit den Diagrammen

 

Neben den verbesserten inhaltlichen Konzepten wurde auch einiges für den Zeichenalltag getan. Sprungmarken vermeiden längere Kanten in Aktivitätsdiagrammen und ersparen aufwändige Layouttätigkeiten. Unterbrechungsbereiche (ebenfalls in Aktivitätsdiagrammen) gruppieren Aktionen und ermöglichen den „Sprung“ aus einer beliebigen gruppierten Aktion, auch wenn an dieser keine passende Ausgangskante modelliert wird. Es genügt den Unterbrechungsbereich mit einer Kante zu versehen, diese erstreckt sich analog auch für alle gruppierten Aktionen. Dies ist besonders effizient für asynchrone Ereignisse, beispielsweise für die Darstellung von Fehlerfällen, die in jeder Aktion der Aktivität auftreten können. Anstatt mehrfach von jeder Aktion eine ausgehende Kante anzutragen, kann eine einzige Kante für alle Element einer Aktionsgruppe gelten.

Abbildung 8Die Alkoholkontrolle aus Abbildung 8 als Timing-Diagramm
Die Alkoholkontrolle aus Abbildung 8 als Timing-Diagramm
(click on image to enlarge!)

back to top   Und wo hat sich nichts getan?

 

Obwohl Version 2.0 einen numerisch nominell großen Revisionsschritt der Sprache darstellt, und gerade die Verhaltensdiagramme generalüberholt wurden, existieren auch Bereiche, in denen sich nichts oder für den Praktiker kaum Spürbares verändert hat. Beispielsweise bei den Use-Case-Diagrammen. Wie bisher besteht die Möglichkeit, die wichtigen Use Cases eines Systems mit Akteuren in Zusammenhang zu setzen. Der Begriff des „Systems“ wurde dabei deutlicher gefasst. Faktisch kann jeder Classifier (also auch Klassen, Komponenten oder Geräte) Use Cases realisieren.

Auch die Kommunikationsdiagramme sind im eigentlichen Sinne, abgesehen von ihrem Namen, nicht neu. Bisher hießen sie Kollaborationsdiagramme, obwohl sie eigentlich schon immer Interaktionen zeigten und nicht nur UML Kollaborationen. Anzumerken ist, dass sie nicht mehr, wie in der Vorgängersprachversion, äquivalent zum Sequenzdiagramm definiert sind, sondern nur eine Teilmenge der dort darstellbaren Konzepte fokussieren.

back to top   Fazit und Resumé

 

Sie sehen -- es hat sich einiges getan in der UML! Es gibt kaum ein Diagramm, an dem sich durch den Versionssprung auf 2.0 nichts geändert hat.
In der Überblicksbewertung fallen hauptsächlich folgende Änderungsbereiche auf:

Damit drängt sich natürlich die Frage auf: Für wen lohnt es sich, auf den neuen Standard umzusteigen?

Diese Frage lässt sich naturgemäß nicht pauschal beantworten. Aber es gibt Indikatoren, welche die Entscheidungsfindung untersützen. Sie sollten einen Umstieg auf den neuen Standard dann ernsthaft in Erwägung ziehen, wenn mindestens einer der folgenden Punkte auf Ihr Projekt oder Unternehmen zutrifft:

Bevor Sie umsteigen, sollten Sie allerdings die UML 2-fähige Version Ihres Modellierungswerkzeuges auf Herz und Nieren testen, denn Toolprobleme können die Vorteile der neuen Sprachversion schnell zunichte machen. Infos über die UML 2-Fähigkeit von Tools finden Sie hier. In weiser Voraussicht kommt der neue Standard den Tool-Herstellern hier entgegen: Die UML ist unterteilt in drei verschiedene Compliance Levels (Erfüllungsebenen) und diese wiederum in Compliance Points (Erfüllungspunkte). Dahinter steckt die Idee, dass auch weniger UML immer noch UML ist: ein Werkzeughersteller muss nicht den gesamten Standard umsetzen, sondern hat die Möglichkeit der schrittweisen Implementierung des definierten Sprachumfanges. Inwieweit ein Tool die UML 2.0 bereits unterstützt, lässt sich neben den Erfüllungspunkten an vier verschiedenen Erfüllungsgraden (nicht erfüllt/teilweise erfüllt/vollständig erfüllt/Austauschformat erfüllt) ablesen, die ein Hersteller angeben muss. Wenn Sie (noch) kein ausgereiftes UML 2-Tool, sondern einfach nur schnelle Hilfe beim Erstellen von Diagrammen benötigen, finden Sie unter www.sophist.de eine Schablone für das Zeichenprogramm MS Visio, die alle wesentlichen graphischen Neuerungen der UML 2.0 enthält.

Insgesamt betrachtet lässt sich konstatieren, dass die Überarbeitung der UML als im Großen und Ganzen geglückt bewertet werden kann. Von den Änderungen profitieren spezielle Anwendungsbereiche wie die Entwicklung von eingebetteten oder Realzeitsystemen, aber auch der „normale“ UML-Anwender profitiert von neuen Möglichkeiten, beispielsweise einer besseren Verständlichkeit durch die Überarbeitung der Hintergrundkonzepte oder durch sich eröffnende Austauschmöglichkeiten zwischen den verschiedensten Werkzeugen.

back to top   Links und Referenzen

 

[Bro75]  F. P. Brooks: Vom Mythos des Mann-Monats, MITP, 2003.

[Har87]  D. Harel: Statecharts: A Visual Formalism for Complex Systems, Science of Computer Programming (8), Elsevier, 1987.

[Oes03]  B. Oestereich, C. Weiss, C. Schröder, T. Weilkiens, A. Lenhard: Objektorientierte Geschäftsprozeßmodellierung mit der UML, dpunkt.verlag, 2003.

[ITU99]  International Telecommunication Union (Hrsg.): Formal Description Techniques -- Message Sequence Charts, ITU-T Recommendation Z.120, 11/1999.

[Born]  M. Born, E. Holz, O. Kath: Softwareentwicklung mit der UML 2, Addison-Wesley, 2003.

Webseite zum Buch UML 2 Glasklar

UML-Werkzeugübersicht




separator line
Service provided by Mario Jeckle
Generated: 2004-05-16T07:57:15+01:00
Feedback Feedback       SiteMap SiteMap
This page's original location This page's original location: http://www.jeckle.de/UML2Artikel-OS.html
RDF metadata describing this page RDF description for this page