UML-Diagramme von Multithread-Anwendungen

Für Single-Threaded-Anwendungen verwende ich gerne Klassendiagramme, um einen Überblick über die Architektur dieser Anwendung zu erhalten. Diese Art von Diagramm war jedoch nicht sehr hilfreich, wenn Sie versuchen, Anwendungen mit vielen Threads / gleichzeitigen Threads zu verstehen, zum Beispiel, weil verschiedene Instanzen einer Klasse in verschiedenen Threads "leben" (dh der Zugriff auf eine Instanz wird nur von der einen gespeichert) Faden lebt es weiter). Infolgedessen bedeuten Zuordnungen zwischen Klassen nicht unbedingt, dass ich Methoden für diese Objekte aufrufen kann, sondern dass ich diesen Aufruf für den Thread des Zielobjekts ausführen muss.

Die meiste Literatur, die ich über das Thema wie das Entwerfen von gleichzeitigen, verteilten und Echtzeitanwendungen mit UML von Hassan Gomaa ausgearbeitet habe, hatte einige nette Ideen, wie das Zeichnen von Fadengrenzen in Objektdiagrammen, aber insgesamt schien es ein bisschen zu akademisch und wortreich zu sein wirklich nützlich sein.

Ich möchte diese Diagramme nicht als allgemeine Ansicht der Problemdomäne verwenden, sondern als detaillierte Beschreibung meiner Klassen / Objekte, ihrer Wechselwirkungen und der Einschränkungen aufgrund der oben erwähnten Threadgrenzen.

Ich würde deshalb gerne wissen:

1. Welche Diagrammtypen haben sich für das Verständnis von Multithread-Anwendungen als hilfreich erwiesen?
2. Gibt es Erweiterungen der klassischen UML, die die Besonderheiten von Multithread-Anwendungen berücksichtigen, z. B. durch Anmerkungen, die dies veranschaulichen?
   • Einige Objekte befinden sich möglicherweise in einem bestimmten Thread, während andere keine Thread-Affinität aufweisen.
   • Einige Felder eines Objekts können von einem beliebigen Thread gelesen, aber nur von einem Thread beschrieben werden.
   • Einige Methoden sind synchron und geben ein Ergebnis zurück, während andere asynchron sind und Anforderungen in die Warteschlange stellen und Ergebnisse beispielsweise über einen Rückruf in einem anderen Thread zurückgeben.

Die wichtigsten Erkenntnisse darüber, wie Thread-Ausführungen ablaufen, können in einem sogenannten Sequenzdiagramm dargestellt werden . Hier ist ein Beispiel aus Wikipedia

Dieses Diagramm zeichnet im Wesentlichen die Liste der Ereignisse zusammen mit einer Richtung über eine vertikale einzelne Linie, die oft als Lebenslinie bezeichnet wird . In diesem Fall ist jeder Thread Eigentümer seiner eigenen Lebenslinie. Das Diagramm ermöglicht die Darstellung aller Arten von Ereignissen wie synchron, asynchron usw.

Das andere wichtigste in solchen Systemen sind die Zustandsdiagramme oder Zustandsdiagramme. Dies gilt normalerweise nur, wenn das Modell als Zustandsmaschine dargestellt wird. In den meisten Multi-Thread-Systemen (bei denen Threads nicht trivial sind) ist es jedoch am besten, wenn sie so konzipiert sind, dass sie mit isolierten Algorithmen für verschiedene Zustände funktionieren.

Es gibt andere Diagrammtypen wie Interaktionsdiagramm und Kommunikationsdiagramm, aber ich denke, dass der Versuch, Sequenzdiagramme und Zustandsdiagramme zu zeichnen , maximale Klarheit bringt.

Meine Antwort ist insofern komplementär zu Dipans , als es sich um UML-Sequenzdiagramme handelt. Ich fand, dass ein Stil, der nicht zu 100% aus UML besteht, auch in Ordnung ist. Schauen Sie sich die in Concurrency Patterns verwendeten Diagramme an . Einige sind fast UML-ähnlich (aber dies ist definitiv kein Standard):

Wenn Sie mit dem Warten / Benachrichtigen in der Java-Thread-Synchronisation vertraut sind, werden Sie das folgende Sequenzdiagramm aus dem erwähnten Dokument zu schätzen wissen:

Bei Anwendungen mit mehreren Threads, die dieselbe Klasse verwenden, kann der Trick darin bestehen, dieselbe Klasse in jedes Modell zu ziehen und dort abzulegen, das einen Thread darstellt. Sie könnten dieselbe Klasse mit verschiedenen Ansichten haben und im Modell und Code navigieren, indem Sie auf die Klasse, das Diagramm oder den Code klicken. Ich weiß, dass die Modellzusammenführung kein bekanntes Konzept ist, aber in Eclipse mit Omondo sehr gut funktioniert.

Ich meine das, wenn ich eine große Anwendung modelliere, die aus mehr als einem Projekt besteht. Ich erstelle für jedes Projekt ein Modell und füge sie dann in einem größeren Projekt zusammen. Die gesamte Modellierung erfolgt mithilfe von Klassendiagrammen. Dies ist das Modell, das ich beim Umkehren des gesamten Projekts von Java-Code zu UML erhalten habe. Ich meine, dass ich in meinem Beispiel vorhandenen Code verwende und ihn in ein einziges UML-Modell umwandle und dann diesen gesamten Umkehrcode, der UML-Modelle erstellt hat, in ein einziges großes Modell zusammenführe. Sie können auch mehrere Modelle erstellen, anstatt vorhandenen Code umzukehren. Es funktioniert in beide Richtungen - bei der Erstellung ohne Code oder in der Reverse Engineering-Phase mit vorhandenem Code.

Ich weiß nicht, ob es sinnvoll ist, aber Sie könnten vielleicht ein großes Modell erstellen und Untermodelle für jeden Thread neu gruppieren, wie bei der Modellierung mehrerer Projekte? Ich hoffe das hilft.