Comelio GmbH UML Interaktionsdiagramm Anleitung Modeling Notation Language Unified UML Manual Handbuch Diagramme Stuttgart Lübeck Ol Ingolstadt Andernach Hannover Hamburg Heidelberg Koblenz Rügen Kassel Freiburg Würzuburg Zwickau Köln Erlangen Bochum Bremen Frankfurt Leipzig Kiel Göttingen Magdeburg Mannheim Koblenz Berlin Ludwigshafen München Wolfsburg Bonn Aachen

Die Interaktionsdiagramme verhelfen generell sowohl Entwicklern als auch Planern, den Informationsaustausch zwischen den Kommunikationspartnern aufzuzeigen. Die einzelnen Kommunikationspartner tauschen dabei Daten und Nachrichten aus. Eines der Interaktionsdiagramme ist das so genannte Sequenzdiagramm, das hauptsächlich für den Fundamental-Test von großer Bedeutung ist. Mit seiner Hilfe wird der Nachrichtenfluss zwischen einzelnen Objekten beschrieben und daneben die chronologischen Abläufe dargestellt. Die Beziehung zwischen den einzelnen Kommunikationspartnern ist hierbei nicht das Thema des Sequenzdiagramms, hier findet der Entwickler im Kommunikationsdiagramm der UML 2.0 mehr Informationen. Dabei können Kommunikationspartner sowohl Objekte als auch Systeme sein. In der Praxis sieht man sehr häufig den Einsatz der Sequenzdiagramme als Interaktionsdiagramm, wobei darüber hinaus noch weitere Interaktionsdiagramme existieren, zum Beispiel das Kommunikationsdiagramm. Das Kommunikationsdiagramm hat seinen Schwerpunkt in der Darstellung der Beziehung der Kommunikationspartner zueinander.

In der UML 2.0 wird ein spezielles Ereignismodell beschrieben, das das Auftreten von Ereignissen sehr genau semantisch erklärt. Anhand des Metamodells in Abbildung 5.1: Events möchten wir Ihnen diese Begrifflichkeiten näher bringen.

Grundsätzlich wird der zugrunde liegende Typ Event genannt. Es gibt, wie man sich logisch vorstellen kann, ein Sendeereignis (Spezifikation: SendOperationEvent) und ein Empfangsereignis beim Empfänger (Spezifikation: CallEvent). Der Fall, dass bei einer Nachricht nur ein Ereignis eintritt, wird später noch genauer beschrieben, dies ist bei den so genannten lost and found messages der Fall. Sie sollten sich die verschiedenen Ereignistypen für die Prüfung merken und deren Sinn nachvollziehen.

Wie Sie in Abbildung 5.1: Events sehen können, gibt es mehrere Formen der Ereignisauftritte.

Eventtyp	Bedeutung
ExecutionEvent	Ein Ereignis, das bei der Ausführung ausgelöst wird
CreationEvent	Ein Ereignis, das ein neues Objekt instanziert
MessageEvent	Ein Ereignis, das eine Nachricht generiert
DestructionEvent	Ein Ereignis, das ein Objekt zerstört

Ohne Zweifel ist, wie schon angedeutet, das Sequenzdiagramm (Spezifikation: Sequence Diagram) neben dem Timingdiagramm ein sehr wichtiges und sicherlich auch von der Aussagekraft her das umfangreichste Interaktionsdiagramm. Es geht bei diesem Diagramm vor allem um die genaue chronologische Reihenfolge des Nachrichtenaustausches. Das Wissen rund um das Sequenzdiagramm wird in der Prüfung abgefragt.

Das Kommunikationsdiagramm (Spezifikation: Communication Diagram) zeigt wiederum eher die Beziehung zwischen den beteiligten Kommunikationspartnern auf. Somit kann man mit Hilfe des Kommunikationsdiagramms den Austausch von Nachrichten darstellen, die zur Lösung einer gemeinsam gestellten Aufgabe innerhalb eines Systems oder systemübergreifend notwendig sind. Das Kommunikationsdiagramm ist nicht prüfungsrelevant.

Mit dem Timingdiagramm (Spezifikation: Timing Diagram) können Zustandswechsel genauestens analysiert werden. Hier können vor allem technische Probleme beschrieben werden, wobei Automaten sicherlich der häufigste Anwendungsfall für ein Timingdiagramm seien werden. Somit können zum Beispiel Prozesse in einem Parkautomaten beschrieben werden, der sich so lange im Zustand „Warten“ befindet, bis eine Münze eingeworfen wird. Dann bleibt er so lange im Zustand „Geldeinwurf“, bis der entsprechende Betrag übereinstimmt, oder sogar überbezahlt ist. Das Timingdiagramm ist nicht prüfungsrelevant.

Die Abhängigkeiten der Interaktionspakete sind in Abbildung 5.2: Abhängigkeiten des Pakets Interaktionen aus der Spezifikation zusammengestellt.

Wie Sie in Abbildung 5.2: Abhängigkeiten des Pakets Interaktionen sehen können, bezieht das Paket BasicInteractions die beiden Pakete BasicBehaviors und InternalStructures ein und importiert die BasicActions. Dies bedeutet, dass die Basis-Interaktionen direkt das Basisverhalten implementiert haben und nutzen können. Es gelten also die Gegebenheiten des bereits beschriebenen Verhaltens in dem entsprechenden Kapitel dieses Buches.

Da bei der Fundamental-Zertifizierung ausschließlich Fragen zum Sequenzdiagramm gestellt werden, werden wir im Folgenden den Schwerpunkt auf die Sequenzdiagramme legen.

Einsatz des Sequenzdiagramms

Wie schon erwähnt, gibt es mehrere Interaktionsdiagrammformen. Hier beim Sequenzdiagramm geht es um den zeitlichen Verlauf der Nachricht, was sich anhand des Sequenzdiagramms sehr gut veranschaulichen lässt. Die Sequenzdiagramme können Sie in sehr verschiedenen Abstraktionsniveaus modellieren. Dabei ist es möglich, die Geschehnisse in einer Klasse selbst zu modellieren, aber auch die Geschehnisse zwischen Komponenten oder des Systems. Die große Stärke der Sequenzdiagramme entfaltet sich allerdings im Projekt während der Implementierungsphase. Sinnvoll sind sie z.B. bei einigen Vorüberlegungen und bei der Fehleranalyse, allerdings sind sie auch in jeder Phase des gesamten Projekts einsetzbar. Sich über die genaue Kommunikation Gedanken zu machen, kann im Übrigen sehr zeitaufwendig sein. Dies führt häufig dazu, dass man bei der Dokumentation nachlässig vorgeht.

Häufig nutzt man das Aktivitätsdiagramm dazu, sich die gezeichneten Anwendungsfalldiagramme genauer anzusehen und sich den objekt- und datenorientierten Klassen-, Fach- oder Analysemodellen zu widmen. Hier geht es darum, komplexere Reihenfolgen und Abläufe und die verschiedenen Varianten darzustellen.

Das Metamodell

Zunächst einmal zum Metamodell der UML 2.0, das in Abbildung 5.3: Lebenslinien genau erläutert wird.

Eine Lebenslinie (Spezifikation: Lifeline) beschreibt ein Objekt und dessen Lebenszeit im Kontext des Kommunikationsprozesses. Sie dient, wie Sie in Abbildung 5.3: Lebenslinien des Metamodells erkennen, der Interaktion. Eine Interaktion kann mehrere Lebenslinien besitzen, umgekehrt kann die Lebenslinie selbst nur zu einer Interaktion gehören. Auf einer Lebenslinie können Ereignisse auftreten, die im Modell als OccurrenceSpecification dargestellt werden. Es gibt auch Zustände oder Referenzen auf andere Nachrichten, die hier übergeordnet Interaktionsfragment (Spezifikation: InteractionFragment) genannt werden. Ein solches Fragment kann, wie Sie in Abbildung 5.3: Lebenslinien sehen, zu mehreren Lebenslinien gehören, des Weiteren kann eine Lebenslinie zu mehreren Fragmenten gehören. Die Fundamental-Prüfung geht auf dieses Thema nicht direkt ein. Insgesamt gilt die Empfehlung, sich für die Prüfung die Multiziplitäten und Beziehungen in den Metamodellen genau anzusehen und nachzuvollziehen. Die Zustandsinvariante (Spezifikation: StateInvariant) ist eine Bedingung (Spezifikation: Constraint), die sich auf Kommunikationsteilnehmer der Interaktion bezieht. Somit kann damit eine Lebenslinie direkt mit einer Bedingung behaftet werden, die zur Laufzeit vor dem nächsten Ereignis beachtet wird. Sie gibt Bedingungen vor, die in geschweiften Klammern oder als Kommentar an die Lebenslinie gehaftet werden. Eine praktischere Erläuterung gibt es nachfolgend in diesem Kapitel, hier soll erst das Metamodell behandelt werden.

Die Interaktionsfragmente sind auch wieder Teil der Interaktion und davon abgeleitet gibt es wiederum die verschiedenen Spezifikationen: ExecutionSpecification, OccurenceSpecification und StateInvariant. Jedes Interaktionsfragment ist selbst wiederum ein benennbares Element.

Abbildung 5.5: Occurrences zeigt Ihnen noch die OccurrenceSpecification anhand des Metamodells auf.

Die ExecutionOccurrenceSpecification ist direkt von der OccurrenceSpecification abgeleitet Die OccurrenceSpecification ist direkt mit einem Ereignis verbunden. Abbildung 5.5: Occurrences listet die Möglichkeiten der verschiedenen Events auf. Die eigentliche Ausführung (Spezifikation: ExecutionSpecification) wird durch die ExecutionOccurrenceSpecification beschrieben. Hier werden auch der Start und das Ende notiert und die Events entsprechend zugeordnet. Die ExecutionSpecification leitet die Aktionen beziehungsweise das Verhalten ab, die wiederum in den ActionExecutionSpecifications und den BehaviorExecutionSpecifications genau beschrieben werden.

Abbildung 5.6: Message zeigt die Interaktion, die die Message besitzt. Eine Interaktion kann, wie Sie sehen, mehrere Messages erhalten, umgekehrt kann eine Message aber nur einer einzigen Interaktion zugeordnet sein. Die Message selbst kann durch verschiedene Typen repräsentiert sein. Diese Typen werden durch die folgenden beiden Aufzählungstypen (Spezifikation: Enumerations) definiert:

Später im Abschnitt über die Nachrichten in diesem Kapitel werden wir uns den einzelnen verschiedenen Aufzählungen der beiden Aufzählungstypen noch genauer widmen.

Für das Sendeereignis und zugleich für das Empfangsereignis gibt es in obigem Metamodell die Klasse MessageEnd. Die Multiplizität 0..1 gibt es natürlich, weil es Nachrichten gibt, die gefunden oder verloren oder gemäß des Aufzählungstyps MessageKind lost oder found sind. Die Klasse MessageEnd steht in einer Assoziationsverbindung zur Klasse Message, weil das Ende der Nachricht meistens mit einer Rücknachricht verbunden ist.

Die MessageOccurrenceSpecifications für Messages und MessageEvents dient der Beschreibung von Ereignissen beim Auftreten der Messages. Dabei beschreibt sie im Gegensatz zur OccurrenceSpecification nur die Ereignisse vom Typ MessageEvents.

Die Signatur wird mit einem NamedElement dargestellt, das als Assoziation in der Rolle (+/signature) repräsentiert wird. Die Signatur besteht aus dem Namen und den Parametern einer Nachricht selbst. Die Parameter werden durch die Kompositionsbeziehung der Message mit den ValueSpecifications beschrieben.

Nachrichten können auch über Konnektoren verschickt werden (Spezifikation: Connector). Ein Konnektor stellt eine Kommunikationsverbindung zwischen so genannten connectable elements dar. Hierbei handelt es sich um Notationselemente des Kompositionsstrukturdiagramms, wie Parts und Ports. Die Kompositionsstrukturdiagramme sind nicht Bestandteil der Fundamental-Prüfung, so dass wir in diesem Zusammenhang nicht weiter darauf eingehen werden.

Abbildung 5.7: CombinedFragments des Metamodells beschreibt die kombinierten Fragmente (Spezifikation: combined fragments).

Ein CombinedFragment definiert einen Ausdruck eines InteractionFragment. Mit einem CombinedFragment umschließt man einen Teilbereich einer Interaktion, in dem bestimmte Regeln gelten. Für die Fundamental-Prüfung sollte man lediglich einmal von diesem Thema gehört haben, direkt prüfungsrelevant ist es nicht.

Im Modell besteht ein InteractionFragment aus Interaktionsoperanden (Spezifikation: InteractionOperand). Diese Interaktionsoperanden, von denen es in der UML 2.0 zwölf gibt, legen die gültigen Regeln fest. Auch hierüber werden wir Sie noch gesondert im Verlauf des Kapitels informieren.

Mit Hilfe der InteractionConstraints werden die Bedingungen festgelegt, mit denen die Interaktionsoperatoren gesteuert werden.

Notationen von Sequenzdiagrammen

Interaktion

Eine Interaktion wird in den UML-Zeichnungen von einem Rahmen umschlossen. Durch diesen Rahmen, der grundsätzlich einen Interaktionsnamen trägt und Übergabeparameter enthalten kann, kann man die Interaktion benennen, referenzieren und finden. Meistens wird das Kürzel sd dem Namen vorangestellt, was so viel heißt wie sequencediagram.

Lebenslinie

Die Zeit wird auf der Lebenslinie von oben nach unten notiert und dargestellt. Die Lebenslinie wird als rechteckiger Kasten mit einer gestrichelten Linie notiert.

Im Rechteck wird der Name des Kommunikationspartners angegeben. In den meisten Fällen handelt es sich dabei um ein Objekt, also eine Instanz. Auch eine andere Symbolik ist gestattet, wenn zum Beispiel dieses Objekt einen Akteur darstellen soll, dann darf auch die entsprechend erlaubte Notation benutzt werden. Wichtig ist es, hier zu beachten, dass eine Lebenslinie einen Kommunikationsteilnehmer darstellt. Es darf hierbei auch nur ein einziger Teilnehmer mit einer Lebenslinie beschrieben werden. In der UML 1.* waren Multiobjekte erlaubt, hier in der UML 2.0 nicht mehr. Ein Teilnehmer kann hierbei nur ein Teil oder eine Einheit eines Classifiers sein, der wiederum seinerseits mit anderen Teilnehmern kommunizieren kann. In der Spezifikation ist dies ein ConnectableElement, das z.B. durch einen Port innerhalb der UML 2.0 realisiert wird. Deswegen muss im Gegensatz zur UML 2.0 das Objekt an dieser Stelle nicht unterstrichen werden. Eine Lebenslinie kann also enthalten:

Eine Lebenslinie enthält in der UML 2.0 zwingend einen Namen des Kommunikationspartners, es ist nicht erlaubt, Lebenslinien anonym zu belassen. Im Kopf einer Lebenslinie steht der Elementname mit dem zugehörigen Classifier in der üblichen Deklarationsnotation, also:

Es kann auch das Schlüsselwort self vorangestellt werden. In diesem Fall repräsentiert die Lebenslinie dann ein Exemplar des Classifiers, dessen Interaktion sie darstellt.

Aktionssequenz

Während des Zeitverlaufes wird ein Objekt in gewissen Abständen etwas tun. Zum Beispiel werden Methoden ausgeführt, Werte gesetzt und vieles mehr. Die Phase, in der ein Objekt aktiv etwas tut, kann man auf der Lebenslinie notieren. Dies geschieht durch Aktionssequenzen (Spezifikation: ExecutionOccurences). Sie werden als zusätzliche Balken, die auch kaskadiert dargestellt werden können, sofern mehrere Aktivitäten gleichzeitig verlaufen, auf der Lebenslinie dargestellt (siehe Abbildung 5.9: Lebenslinie mit einer Aktionssequenz).

Der Anfang und das Ende des Ausführungsknotens werden durch Ereignisauftritte (Spezifikation: ExecutionEvents) definiert. Diese Ereignisauftritte sind vom Auftritt einer eingehenden Nachricht und dem Versenden eines Nachrichtenaustritts abhängig, wie Sie in Abbildung 7.9 sehen können. Sowohl beim Start als auch beim Ende werden die Ereignisse durch die ExecutionOccurrenceSpecifications beschrieben. Das Eintreffen eines Ereignisses kann auch bedeuten, dass eine neue Lebenslinie generiert wird.

Zustandsinvarianten auf Lebenslinien

Eine Zustandsinvariante (Spezifikation: StateInvariant) wird auf der Lebenslinie selbst notiert. Sie stellt eine Bedingung (Spezifikation: Constraint) dar. Vor Eintreten des zeitlich nächstgelegenen Ereignisses auf der Lebenslinie wird diese dann ausgewertet. Weiter in der Beschreibung mit der UML 2.0 ginge es in diesem Falle mit dem Zustandsdiagramm, was aber für die Fundamental-Prüfung irrelevant ist. Hier jedenfalls bewirkt die Zustandsinvariante keine Änderung des Zustandes, in dem sich das repräsentierte Objekt befindet. Allerdings ist die Interaktion dann fehlerhaft.

In den Abbildungen 5.10 bis 5.12 sind die gültigen Notationsformen dargestellt.

Für welche Notation Sie sich in der Praxis entscheiden, bleibt Ihnen überlassen, für die Prüfung sollten Sie sich allerdings die drei verschiedenen Darstellungsformen merken.

Nachrichten

Wie Sie in allen bisherigen Abbildungen bereits sehen, werden Nachrichten (Spezifikation: Messages) mit Pfeilen notiert. Hierbei unterscheidet man mehrere Möglichkeiten.
Synchrone Nachricht

Die synchrone Nachricht (Spezifikation: Synchronous Message) wird mit einer geschlossenen Pfeilspitze dargestellt. In diesem Fall wartet die aufrufende Lebenslinie, bis das aufgerufene Verhalten seine Aufgabe verrichtet hat.

Es gibt vom aufgerufenen Verhalten eine Antwort (Spezifikation: Reply Message), die mit einer gestrichelten Linie und einer offenen Pfeilspitze repräsentiert wird.

Im Gegensatz zur synchronen Nachricht wird bei der asynchronen Nachricht (Spezifikation: Asynchronous Message) nicht auf das aufrufende Verhalten gewartet, sondern es wird einfach mit dem eigenen Verhalten fortgefahren. Logischerweise ist hier auch keine Antwort nötig.

Eine verlorene Nachricht (Spezifikation: Lost Message) hat eine offene Pfeilspitze, die in einem gefüllten Kreis endet. Dass die Pfeilspitze in diesem Fall nicht mit einer Lebenslinie verbunden ist, soll andeuten, dass die Nachricht verloren ist. Der Empfänger ist zudem nicht bekannt, wohl aber der Sender.

Der umgekehrte Fall ist auch notierbar und stellt eine gefundene Nachricht (Spezifikation: Found Message) dar. Die Linie geht vom Kreis aus und trifft mit der Pfeilspitze eine Lebenslinie. Der Empfänger ist hier bekannt, nicht aber der Sender.

Create

Create ist eine Nachricht, die ein neues Objekt erstellt. Diese Nachricht wird im Normalfall durch einen gestrichelten Pfeil mit einer offenen Pfeilspitze repräsentiert. Man kann diesen Pfeil allerdings auch als normalen asynchronen Pfeil wie in Abbildung 5.17: Create-Nachricht notieren. Die neue Lebenslinie des neuen Objektes beginnt erst beim Versand der Nachricht. Somit ist es nur logisch, dass der Pfeil auf den Kopf der neuen Lebenslinie zeigt.

Hierbei ist noch wichtig zu bemerken: In der Spezifikation wird der Pfeil für Create gestrichelt angegeben. In vielen Programmen wird er aber durchgezogen dargestellt, was durchaus gängige Praxis ist. Falls diese Frage in der Prüfung gestellt wird, liegen Sie richtig, wenn Sie diesen Pfeil wie den Antwortpfeil gestrichelt notieren.

Syntax einer Nachricht

Die Nachricht selbst kann einige Syntaxelemente enthalten, die die Nachricht genauer beschreiben. Eine Nachricht hat folgenden grundlegenden Aufbau:

Syntax	Bedeutung
attribut	Variable, die während der Interaktion übergeben wird. Das Attribut kann nur bei einem synchronen Aufruf mit einem Rückgabewert genutzt werden.
name	Hiermit wird der Name der aufzurufenden Nachricht angegeben. Bei einem Signal wird hier ebenfalls der Name des Signals angegeben, wobei ein Signal immer asynchron ist.
argumente	Mit Argumenten werden Nachrichten Parameter mitgegeben. Parameterübergaben sind bereits im Kapitel Klassendiagramme behandelt, die Gegebenheiten sind hier identisch.

Mit einem Sequenzdiagramm kann man ein Objekt erzeugen, wie Sie gelernt haben. Man kann ein Objekt aber auch entfernen. Dies wird durch ein Kreuz auf der Lebenslinie dargestellt. Neuerdings, also in der UML 2.0, wird die Zerstörung eines Objektes als Stopp (Spezifikation: Stop) bezeichnet, der wiederum einen speziellen Ereignisauftritt (Spezifikation: EventOccurence) darstellt.

Ereignisse bei Nachrichten

Ereignisse treten grundsätzlich unmittelbar nach dem Senden oder Empfangen von Nachrichten auf. Bei den Abfolgen von Nachrichten gibt es noch eine Besonderheit, die oft in der Prüfung nachgefragt wird. Dabei gibt es mehrere gültige Abfolgen von Nachrichten. Wenn Sie hier für klare Verhältnisse sorgen möchten, können Sie noch zusätzliche Anmerkungen anbringen. In der UML 2.0 ist es grundsätzlich zwingend, dass zuerst das Sendeereignis stattfindet. Danach erst kommt das zugehörige Ereignis, das den Empfang repräsentiert.

Entlang einer Lebenslinie ist die Reihenfolge eingehalten. Die gegenüberliegende Lebenslinie ist aber nur relativ dazu. Die Zeitachse kann quasi (schneller oder langsamer) beschriftet werden.

Schaut man sich einmal die Abfolgen an und geht mit dem normalen Menschenverstand vor, so meint man zunächst, dass die Kommunikation von A nach B verläuft und dann von C nach D. Dies ist auch so weit richtig. Aber dass die Kommunikation von C nach D anfängt, bevor die Kommunikation von A nach B abgeschlossen ist, bleibt unklar. Somit kann das Sendeereignis A anfangen und dann das Sendeereignis C beginnen, noch bevor das Empfangsereignis B eingetroffen ist.

Wichtig ist, dass grundsätzlich erst ein Sendeereignis auftaucht, bevor das entsprechende, also zu dem Sendeereignis gehörige, Empfangsereignis eintritt. Das ist so weit banal. Des Weiteren ist noch wichtig, dass auf einer Lebenslinie die Zeit chronologisch verläuft. Allerdings kann auf einer parallelen Lebenslinie die Zeit anders skaliert werden, so dass quasi dieselbe Position in einem Diagramm auf zwei verschiedenen Lebenslinien nicht den gleichen Zeitpunkt darstellt.

Um diesen Umstand der Ungenauigkeit zu vermeiden, gibt es eine Möglichkeit, Ordnungsbeziehungen (Spezifikation: General Orderings) für dieses Problem zu nutzen. Somit wird die Reihenfolge der Abläufe genau dargestellt.

Bei der Ordnungsbeziehung handelt es sich um eine gepunktete Verbindung mit einem ausgefüllten Pfeil in der Mitte in einem Sequenzdiagramm zwischen zwei Ereignissen, meist Sende- und Empfangsereignis.

Abbildung 5.20: Ordnungsbeziehung stellt die Ordnung in der Weise her, dass nun klar wird, dass das Startereignis C definitiv vor B stattfinden muss. Die einzige gültige Abfolge wäre hier nunmehr

Comelio GmbH UML Interaktionsdiagramm Anleitung Modeling Notation Language Unified UML Manual Handbuch Diagramme Stuttgart Lübeck Ol Ingolstadt Andernach Hannover Hamburg Heidelberg Koblenz Rügen Kassel Freiburg Würzuburg Zwickau Köln Erlangen Bochum Bremen Frankfurt Leipzig Kiel Göttingen Magdeburg Mannheim Koblenz Berlin Ludwigshafen München Wolfsburg Bonn AachenComelio GmbH UML Interaktionsdiagramm Anleitung Modeling Notation Language Unified UML Manual Handbuch Diagramme Stuttgart Lübeck Ol Ingolstadt Andernach Hannover Hamburg Heidelberg Koblenz Rügen Kassel Freiburg Würzuburg Zwickau Köln Erlangen Bochum Bremen Frankfurt Leipzig Kiel Göttingen Magdeburg Mannheim Koblenz Berlin Ludwigshafen München Wolfsburg Bonn AachenComelio GmbH UML Interaktionsdiagramm Anleitung Modeling Notation Language Unified UML Manual Handbuch Diagramme Stuttgart Lübeck Ol Ingolstadt Andernach Hannover Hamburg Heidelberg Koblenz Rügen Kassel Freiburg Würzuburg Zwickau Köln Erlangen Bochum Bremen Frankfurt Leipzig Kiel Göttingen Magdeburg Mannheim Koblenz Berlin Ludwigshafen München Wolfsburg Bonn AachenComelio GmbH UML Interaktionsdiagramm Anleitung Modeling Notation Language Unified UML Manual Handbuch Diagramme Stuttgart Lübeck Ol Ingolstadt Andernach Hannover Hamburg Heidelberg Koblenz Rügen Kassel Freiburg Würzuburg Zwickau Köln Erlangen Bochum Bremen Frankfurt Leipzig Kiel Göttingen Magdeburg Mannheim Koblenz Berlin Ludwigshafen München Wolfsburg Bonn AachenComelio GmbH UML Interaktionsdiagramm Anleitung Modeling Notation Language Unified UML Manual Handbuch Diagramme Stuttgart Lübeck Ol Ingolstadt Andernach Hannover Hamburg Heidelberg Koblenz Rügen Kassel Freiburg Würzuburg Zwickau Köln Erlangen Bochum Bremen Frankfurt Leipzig Kiel Göttingen Magdeburg Mannheim Koblenz Berlin Ludwigshafen München Wolfsburg Bonn AachenComelio GmbH UML Interaktionsdiagramm Anleitung Modeling Notation Language Unified UML Manual Handbuch Diagramme Stuttgart Lübeck Ol Ingolstadt Andernach Hannover Hamburg Heidelberg Koblenz Rügen Kassel Freiburg Würzuburg Zwickau Köln Erlangen Bochum Bremen Frankfurt Leipzig Kiel Göttingen Magdeburg Mannheim Koblenz Berlin Ludwigshafen München Wolfsburg Bonn AachenComelio GmbH UML Interaktionsdiagramm Anleitung Modeling Notation Language Unified UML Manual Handbuch Diagramme Stuttgart Lübeck Ol Ingolstadt Andernach Hannover Hamburg Heidelberg Koblenz Rügen Kassel Freiburg Würzuburg Zwickau Köln Erlangen Bochum Bremen Frankfurt Leipzig Kiel Göttingen Magdeburg Mannheim Koblenz Berlin Ludwigshafen München Wolfsburg Bonn AachenComelio GmbH UML Interaktionsdiagramm Anleitung Modeling Notation Language Unified UML Manual Handbuch Diagramme Stuttgart Lübeck Ol Ingolstadt Andernach Hannover Hamburg Heidelberg Koblenz Rügen Kassel Freiburg Würzuburg Zwickau Köln Erlangen Bochum Bremen Frankfurt Leipzig Kiel Göttingen Magdeburg Mannheim Koblenz Berlin Ludwigshafen München Wolfsburg Bonn AachenComelio GmbH UML Interaktionsdiagramm Anleitung Modeling Notation Language Unified UML Manual Handbuch Diagramme Stuttgart Lübeck Ol Ingolstadt Andernach Hannover Hamburg Heidelberg Koblenz Rügen Kassel Freiburg Würzuburg Zwickau Köln Erlangen Bochum Bremen Frankfurt Leipzig Kiel Göttingen Magdeburg Mannheim Koblenz Berlin Ludwigshafen München Wolfsburg Bonn Aachen

Interaktionsdiagramme mit der UML

Kontakt

Interaktionsdiagramme

Einsatzgebiet und Modellierung von Interaktionsdiagrammen