Nach dem Tode unseres Ko-Autors Mario Jeckle im Juni 2004 haben wir uns dazu entschlossen, diese Seite zu seinem Gedenken so zu erhalten, wie sie im Juni war. Wir haben daher seither keine Aktualisierungen vorgenommen. Wir entschuldigen uns für alle
damit verbundenen Unannehmlichkeiten und möchten Sie einladen, unsere neue Webseite zum Buch zu besuchen.
Herzlichen Dank!
Herzlich willkommen auf der Seite von UML glasklar!
Wir werden Ihnen auf diesen Seiten regelmäßig Informationen rund um die Unified Modeling Language
(UML) zur Verfügung stellen. Zusätzlich können Sie hier Auszüge aus unserem Buch lesen, ergänzende Beispiele beziehen sowie Lob und Kritik übermitteln. Darauf haben Softwareentwickler und Modellierer lange gewartet: Der Standardisierungsprozess der UML 2 ist abgeschlossen! Die neue Version des Standards für die Modellierung bringt zahlreiche und umfangreiche Änderungen und Verbesserungen, welche die langjährigen Anliegen und Anforderungen tausender UML'ler erfüllen sollen. Die Autoren beschreiben die für die Modellierung relevanten Konzepte und Elemente der UML. Zusätzlich arbeitet sie die Unterschiede der neuen Version gegenüber den älteren heraus. Die Autoren beschreiben den Einsatz der UML mit Hilfe zahlreicher Praxisbeispiele. Auch zeigen sie in beispielhaft die Umsetzung in C++, Java und C#. Folgende Fragen werden u. a. beantwortet.
|
Übrigens: UML 2 glasklar ist das einzige UML Buch am gesamten deutschsprachigen Buchmarkt, das gleichzeitig
Probekapitel: | Das Use Case Diagramm |
ISBN: | 3-446-22575-7 |
Erscheinungsdaten: | 2003-11-24, 446 Seiten, kartoniert, ca. 34,90 EUR |
Leserinfos auf einen Blick: | |
Presseinfos auf einen Blick: | |
Buch direkt bestellen bei: | Carl Hanser Verlag |
UML im Vorbeigehen lernen oder sich einfach nur mit Graphiken aus dem Buch -- wahlweise garniert mit coolem Clubsound -- unterhalten lassen. All das mit unseren UML glasklar Bildschirmschonern, lauffähig auf allen Windowsversionen.
Beide Bildschirmschoner sind von uns auf Viren und andere ungebetene Gäste getestet worden.
Prüfen Sie im Zweifelsfall, ob Sie die Originaldateien geladen haben, die MD5-Checksummen:d7c984268cbc2002f3b662c651f2e491
für die Silent Edition und9f91776a44a0faed847a0cd54b94f2ad
für die Club Edition.
Alles was Sie schon immer über UMLs dynamische Diagramme wissen wollten, und
nicht nachzusehen wagten ;-)
Bildschirmschoner
MD5-Checksumme: 8bd6301eaf445d669af13727a6ed4f95
Frage: In welchem Stadium befindet sich die UML 2.0-Standardisierung? Kann UML 2.0 schon eingesetzt werden?
Antwort: Die Arbeiten an UML 2.0 wurden seitens der Einreicher abgeschlossen und die Spezifikation durch die Analysis and Design Task Force der OMG per Abstimmung angenommen. Ebenso hat das OMG Architecture Board die Spezifikation verabschiedet und in den Stand einer OMG Adopted Specification erhoben.
Mit dem Ende der aktiven Arbeiten und den beiden Abstimmungen hat die UML 2.0 daher ihren endgültigen Ausbaustand erreicht.
In der aktuellen Finalisierungsphase wird die durch die OMG-Gremien angenommende Spezifikation durch die Finalization Task Force überarbeitet und editorielle (hierunter fallen schlichte Tipp- und Kopierfehler) sowie kleinere technsiche Fehler behoben. Die Finalization Task Force wird jedoch keine gravierenden Änderungen (wie die Entfernung bestehender oder Hinzunahme neuer Diagrammtypen) an der bestehenden Spezifikation vornehmen.
Daher kann die Arbeit an UML 2.0 als abgeschlossen angesehen und die aktuelle Spezifikation durchaus für erste Projekte herangezogen werden. Dies illustrieren insbesondere auch Aktivitäten der seitens der Werkzeughersteller, die bereits mit der Implementierung der UML 2.0 in ihren Produkten begonnen haben.
Frage: Welche (bekannten) „Kinderkrankheiten“ der UML 2.0 besitzen das Aktivitäts-, das Sequenz- und das Aktivitätsdiagramm?
Antwort: Das Klassendiagramm weist inzwischen keine Kinderkrankheiten mehr auf. Da es als Basis der gesamten UML auch im Metamodell breite Verwendung findet und mit einer Historie, die bis in die 1970er Jahre zurückreicht, über eine lange Vorgeschichte verfügt sind dessen graphische Primitive inzwischen sehr ausgereift. Einige „klassische Schwächen“ des UML-Klassendiagramms, beispielsweise im Umfeld der Semantikdefinition von Komposition und Aggregation, sind allerdings auch kaum verändert präsent.
Die Verhaltensdiagramme hingegen verfügen über eine deutlich kürzere und gleichermaßen bewegtere Historie. Sie würden erst relativ spät in die UML integriert und in den 1.x-er Spezifikationsversion etwas stiefmütterlich behandelt. In der Version 2.0 wurden alle Diagrammtypen zur Darstellung dynamischen Verhaltens einer deutlichen Überarbeitung unterzogen, welche sich in spürbarem Mächtigkeitsgewinn auszahlt. Allerdings -- und dies bildet sicherlich die prägendste „Kinderkrankheit“ der Version 2.0 -- wurde sowohl auf die konsequente und vollständige Integration der den dynamischen Diagrammen zugrundeliegenden Bassstandards wie MSCs verzichtet, als auch innerhalb der UML keine verbindliche Semantikdefinition festgelegt.
Frage: Welche Neuerungen bei UML 2.0 haben aus Ihrer Sicht die größte Bedeutung?
Wo sehen Sie die wichtigsten Benefits für Entwickler?
Antwort: Der Standardisierungsprozess hat den Wünschen der Anwender an vielen Stellen Rechnung getragen. Gleichwohl präsentiert sich das Update auf 2.0 eher als leise Evolution denn als Revolution, da die an der Standardisierung Beteiligten der Versuchung, eine neue UML zu erfinden, widerstanden haben. In der Menge der Änderungen fallen dem Betrachter vor allem zwei Bereiche auf:
Die Änderungen an der Basis der Sprache und im Bereich der Verhaltensmodellierung.
Das Metamodell der UML wurde grundlegend überarbeitet, insbesondere wurde die semantische Beschreibung der Elemente präziser gefasst sowie Redundanzen und Inkonsistenzen beseitigt. Dadurch ist die UML ist in der neuesten Version kompakter und in sich schlüssiger geworden. Für den Anwender erleichtert dies das Erlernen und die Anwendung der UML, da die vorhandenen Basiskonzepte in verschiedenen Diagrammen mit dem gleichen Verhalten und gleicher Bedeutung eingesetzt werden können. Daneben profitieren von diesen Änderungen in besonderem Maß natürlich auch die Toolhersteller.
Anders als der Bereich der Diagramme zur statischen Modellierung, der vergleichsweise geringfügige Änderungen erfuhr, wurde der Bereich der dynamischen Diagramme einer umfangreichen Umstrukturierung und Erweiterung unterzogen. So wurde die Semantik und Notation des Aktivitäts- wie des Sequenzdiagramms völlig überarbeitet, zwei neue Sichten eingeführt (Timing- und Interaktionsübersichtsdiagramm) und das Kollaborationsdiagramm wurde in Kommunikationsdiagramm umgetauft. Neue Möglichkeiten der Verhaltensmodellierung wie die Schachtelung und Vererbung von Diagrammen oder die Darstellung von verschiedenen Interaktionen in einem Diagramm unterstützen Reengineering-Ansätze und Top-Down-Vorgehensmodelle.
Mit dem Timing-Diagramm und verbesserten Modellierungsmöglichkeiten von zeitlichem Verhalten und Nebenläufigkeit in Interaktionen empfiehlt sich die UML auch stärker als bisher für die Modellierung in der Geschäftsprozessanalyse oder von Systemen im technischen Umfeld. Schließlich verbessern neue Kontrollstrukturen und das von den Petri-Netzen entliehene Tokenkonzept im Aktivitätsdiagramm die Möglichkeiten des Anwenders, Abläufe gezielter zu steuern. Abläufe sind nun durch geeignete Werkzeuge simulierbar und können beispielsweise auf Erreichbarkeit einzelner Kontrollflusszweige und Verklemmungsfreiheit untersucht werden können.
Frage: Es gab die Kritik, UML 2.0 sei mit Features überfrachtet. Ist diese Kritik berechtigt?
Antwort: Auf den ersten Blick mag man angesichts von drei neuen Diagrammen (damit hat die UML jetzt derer 13) und erweiterter Mächtigkeit bei den bereits existierenden den Eindruck gewinnen, das im Zuge der Standardisierung widerspruchslos den Bedürfnissen unterschiedlichster Anwendergruppen nachgegeben wurde. Und sicherlich enthält auch die UML 2.0 Modellierungskonstrukte, denen kaum eine breite Anwendung beschieden sein wird. Dafür präsentiert sich die UML 2.0 mit einer sauberen Basis, einem aufgeräumten und von Redundanzen befreiten Metamodell. Dies macht sie -- trotz aller Erweiterungen -- schlanker und vor allem verständlicher. Sicher gilt auch für die UML 2.0, dass das beste Werkzeug wenig nützt, wenn es falsch eingesetzt wird, aber auch die 1.x-Version erforderte für eine Erfolg versprechende Anwendung im Projekt ein gezieltes Tailoring.
Frage: Wird es für Softwaredesigner und Entwickler eventuell schwieriger, sich in der neuen Version von UML zurechtzufinden?
Wo erwarten Sie Umstellungs-Schwierigkeiten?
Antwort: Für den erfahrenen UML-Anwender gibt es sicherlich einen gewissen Umgewöhnungsbedarf: So hat sich die graphische Repräsentation einiger Elemente geändert (ein Zustand sieht aus wie eine frühere Aktivität) und Bezeichnungen geändert (das frühere Aktivitätsdiagramm heißt jetzt Aktivität und eine Aktivität heißt jetzt Aktion). Ob man das „alte“ Kollaborationsdiagramm nun als Kommunikationsdiagramm bezeichnet, ändert wenig an seiner Anwendung, allerdings ist es nicht mehr äquivalent zum Sequenzdiagramm, da letzteres in seiner Mächtigkeit stark erweitert wurde. Beachten sollte der Anwender außerdem, daß die UML 2.0 in weiten Bereichen nicht abwärtskompatibel zu ihren Vorgängerversionen ist.
Frage: Ab wann erwarten Sie Tools, die UML 2 umfassend oder doch zumindest größtenteils abdecken? Wie kann sich der Entwickler bis dahin helfen?
Antwort: Natürlich können auch wir nur über den Zeitplan von Toolherstellern mutmaßen. Zur Zeit ist noch kein Tool auf dem Markt, das die UML 2.0 angemessen unterstützt. Vermutlich werden viele Toolhersteller die Neuerungen nach und nach übernehmen. In Erwartung dessen wurde die UML im neuen Standard in drei unterschiedlich komplexe Erfüllungsebenen und Erfüllungspunkte eingeteilt, welche wiederum Notationselemente auf einer Ebene zu Gruppen zusammenfassen. Dies ermöglicht den Anbietern von Modellierungstools die schrittweise, auf ihre jeweilige Zielgruppe zugeschnittene Umsetzung der neuen UML-Version.
Frage: Was würden Sie Softwaredesignern/Entwicklern raten, die über einen Wechsel von UML 1.x zu 2.0 nachdenken? Ist ein Wechsel zu 2.0 in jedem Fall notwendig?
Antwort: Die Erweiterungen der dynamischen Diagrammtypen wie beispielsweise das Sequenz- oder Aktivitätsdiagramm sind für sich alleine genommen schon ein guter Grund für den Wechsel. Ein Wechsel ist vor allem dann ratsam, wenn ein wesentlicher Aspekt Ihrer Modellierungstätigkeit auf der Beschreibung des Systemverhaltens liegt und Sie diese Diagramme intensiv nutzen. Gleiches gilt für die Modellierung technischer Systeme, insbesondere wenn Sie die Kommunikation von Komponenten oder das Zeitverhalten eines Systems abbilden wollen.
Sinnvoll ist der Umstieg auf UML 2.0 aber auch, wenn die Sie häufig Datenströme oder Workflows modellieren, wie bei der Darstellung von Geschäftsprozessen. Und schließlich eröffnet Ihnen die UML 2.0 auch neue Möglichkeiten bei der Generierung von Code oder Architekturen basierend auf einem MDA-Ansatz, oder bei sich schnell ändernden, architektonischen Umfeldern wie EAI (Enterprise Application Integration).
Frage: Gibt es Möglichkeiten, die UML eigenen Bedürfnissen anzupassen?
Antwort: Es gibt 2 grundsätzliche Mechanismen die UML zu erweitern:
Letztere ergänzen nur die UML, indem sie das Metamodell der UML unberührt lassen und nur erweitern bzw. gültige Regeln einschränken, es werden aber keine Elemente wie Klassen oder Assoziationen hinzugefügt oder weggenommen. In der UML stehen für diese Anpassungen drei Konstrukte zur Verfügung: Stereotypen, tagged values und in OCL formulierte constraints. Eine konkrete Sammlung dieser Konstrukte bezeichnet man als Profil. Der Begriff bzw. die Idee des Profils hat sich mit der UML 2.0 gegenüber den Vorgängerversionennicht geändert. Allerdings sind Profile inzwischen eigene Metamodell-Elemente der UML, somit können Sie auch Profile modellieren. Profile sind einfach ausgedrückt, nichts anderes als Pakete, deren Elemente in erster Linie Ausprägungen der Anpassungskonstrukte sind.
Frage: Inwieweit werden zukünftig Sequenzdiagramme zur Geschäftsprozessmodellierung an Stelle der Aktivitätsdiagramme eingesetzt werden?
Im Gegensatz zu früheren UML-Versionen ist es ja nun möglich, mittels Sequenzdiagrammen durch die erweiterte Mächtigkeit (Modellierung von Parallelität, Wiederholungen usw.) Abläufe darzustellen.
Antwort: Aktivitätsdiagramme werden in der Geschäftsprozeßmodellierung auch in den nächsten Jahren eine vorherrschende Stellung einnehmen. Insbesondere da viele Umsteiger aus anderen Notationen die prozess- oder flußorientierte Darstellung kennen und sich hier leicht zurecht finden. Zudem wurden grobe Mängel in den UML 1.x Aktivitätsdiagrammen mit der UML 2.0 ausgeräumt (z.B. bietet UML 2.0 verbesserte Konstrukte zur Modellierung des Objektflusses an). Dies macht diese Diagrammart noch attraktiver.
Die Vorteile der Sequenzdiagramme im Vergleich mit den Aktivitätsdiagrammen sind die Möglichkeiten zur präzisen Angabe zeitlicher Abläufe und Ereignisreihenfolgen; besonders im Zusammenhang mit Interaktionen. Deren Bedarf ist für die Geschäftsprozessmodellierung aber eher als gering einzuschätzen. Wenn es auf die reine Darstellung der Kommunikation im Rahmen der Geschäftsprozessmodellierung ankommt, ist ein Kommunikationsdiagramm vorzuziehen.
In zukünftigen UML-Versionen, welche möglicherweise mit einer formalen Grammatik ausgestattet werden werden, dürften die Unterschiede zwischen Aktivitätsdiagrammen und Sequenzdiagrammen vermutlich eher gering sein. Der erste Schritt wurde bereits unternommen, indem die Mechanismenzur Einbindung von Objekten in Aktivitätsdiagramme verbessert wurden. Vielleicht wird es dann möglich sein, auf Knopfdruck zwischen Aktivitätsdiagrammen und Sequenzdiagrammen hin- und herschalten. Es ist auch bezeichnend für die UML 2.0, dass man die Diagramme immer mehr als Sicht (view) auf ein Modell betrachtet. Die Kunst wird in der Zukunft sein, die richtige Sicht (d.h. das richtige Diagramm) auszuwählen.
Frage: Was ist die genaue Semantik einer Aktion, die über mehrere ausgehende Kanten verfügt?
Stimmt es, daß an jeder ausgehenden Kante ein separates Token angeboten wird. Wird daher der Kontrollfluß gemäß der Anzahl der ausgehenden Kanten aufgespalten?
Antwort: Es ist zwar richtig, daß an allen ausgehenden Kanten Tokens angeboten werden, aber hierdurch wird keine nebenläufige Verarbeitung erzeugt. Sobald ein Token von einer Folgeaktion (d.h. von einem Folgeknoten) konsumiert (angenommen) wird, stehen die anderen angebotenen Tokens nicht mehr zur Verfügung. Mit anderen Worten, egal wieviele Tokens am Ausgang einer Aktion zur Verfügung stehen, es verlässt in der Regel nur genau ein Token die Aktion.
Frage: Warum wird im Klassendiagrammkapitel zur Darstellung mengenwertiger Beziehungen die
veraltende Java-Klasse Vector
verwendet?
Antwort: Geschwindigkeitsmessungen zeigen, daß Operationen auf Vector
-Objekten einerseits
deutlich (je nach Rechner bis zu 180%) schneller ausgeführt werden als beispielsweise auf
Ausprägungen von LinkedList
, zum anderen besitzt Vector
einen deutlich
höheren Bekanntheitsgrad als die erst in Java 1.4 eingeführten Nachfolger.
Konzeptionell unterscheidet
sich jedoch die gewählte Implementierung nicht von ihren Nachfolgern, daher kann Vector
ohne Mächtigkeitsverlust gegen eine andere Klasse der Collection-API ausgetauscht werden.
Frage: Falls ein Synchronisationsknoten mit einer OR
join-Spezifikation versehen ist
(siehe Buch S. 237 unten), werden dann ankommende Tokens trotzdem verschmolzen?
Antwort: Leider beantwortet die UML-Spezifikation diesen Sachverhalt nicht
hinreichend, da im Standard nur der „Normalfall“ also das Synchronisieren
mit der Tokenverschmelzung erläutert ist. In unserem Beispiel aus Abbildung
10.74 sind wir eigentlich von einem XOR
ausgegangen, d. h. dass nie
gleichzeitig die Stadt mit dem Auto oder dem Zug besucht wird. Würden
jedoch 2 Tokens vorliegen, d. h. 1 Token in der Aktion Zug fahren und 1
Token in Auto fahren, so dürften die beiden Tokens nicht verschmolzen
werden. Ansonsten wäre die Äquivalenz zum Verbindungsknoten im rechten Teil
der Abbildung nicht gegeben.
Frage: Kann man mit Profilen auch Änderungen am Metamodell durchführen?
Antwort: Nein.
Im allerersten Dokument zu Profilen war dies noch vorgesehen. Davon hat man sich mittlerweile aber verabschiedet. Dummerweise sind in den offiziellen Profildokumenten aber immer Metamodelländerungen aufgeführt, diese befinden sich aber in extra Dokumentabschnitten und gehören streng genommen nicht zu dem Profil an sich.
Frage: Warum gehören eigentlich Use-Cases zu den Verhaltensdiagrammen?
Ein Use-Cases-Diagramm stellt doch eher ein Struktur- als ein Verhaltensdiagramm dar.
Antwort: Im Rahmen der UML 2 wurde der Fokus bei den Use-Case-Diagrammen leicht verschoben. Man sieht nun nicht mehr das Use-Case-Diagramm -- also die Statik -- im Vodergrund, sondern stattdessen den einzelnen Use-Case bzw. seine Beschreibung und die dahinterstehende Abläufe (obwohl diese nicht mit dem Use-Case-Diagramm ausgedrückt werden sondern vielmehr durch Aktivitätsdiagramme, Zustandsautomaten und meist durch Text). Im Metamodell der UML äußerst sich diese Zwitterstellung durch eine Mehrfachvererbung: Ein Use-Case ist dort sowohl ein Classifier (ähnlich wie eine Klasse, also eine statische Schnittstelle) als auch ein Behaviour (ein Verhalten, ähnlich wie eine Aktion). Prinzipiell steht aber die letzte Sichtweise bei den UML-Autoren im Vordergrund und genau deswegen die Verschiebung zu den Verhaltensdiagrammen. Das Use-Case-Diagramm an sich zeigt aber „nur“ statisch die angebotenenen Dienstleistungen. Wobei deutlich herausgestellt wurde, dass ein Use-Case einem beliebigen Classifier zugeordnet werden kann, z.B. auch einer Komponente. Damit modellieren Sie eben das angebotene „Dienstleistungsspektrum“ einer Komponente.
Wir, das sind ...
Mario Jeckle jeckle.de | Chris Rupp Sophist Group | Jürgen Hahn Sophist Group | Barbara Zengler Thebit | Stefan Queins Sophist Group |
Ja, ich möchte regelmäßig (ungefähr alle vier bis sechs Wochen) den UML-Newsletter mit aktuellen Informationen rund um Standardisierung und Einsatz der UML per Mail erhalten...
Service provided by Mario Jeckle
Generated: 2005-01-24T13:08:56+01:00
Feedback SiteMap
This page's original location: http://www.uml-glasklar.de/
RDF description for this page