Wie kann das Ereigniskonstrukt c # .net am besten in einem UML-Klassendiagramm dargestellt werden?
Ich entwerfe ein Entitäts- / Komponentensystem, bei dem das Problem der Kommunikation zwischen Entitäten durch ein Ereignismeldungssystem behoben wird. Komponenten sind in zwei Teile unterteilt, einen in der Entität und eine Art "Entitäts-Proxy" in einem Subsystem, die durch ein System vom Beobachter-Typ synchronisiert werden. Ich versuche eine Implementierung mit Ereignissen und Delegierten.
Ich versuche, die Struktur des Ereignis- / Messagingsystems meiner Anwendung zu modellieren, und habe Probleme mit den Delegierten. So wie es jetzt ist, ist es ein Diagramm (angehängt), das den Delegaten, die eventArgs und die Entitäten im System zeigt. Die Art ihrer Beziehungen wird jedoch nur als generische Assoziationen dargestellt. Ich habe auch ein zweites Diagramm, das die Schnittstellen des Systems zeigt. Ich muss die Ereignisse zeigen, die in diesen Objekten ausgelöst werden, da dies den größten Teil der Komplexität im System ausmacht.
Ich weiß, dass ich dynamische Zusammenarbeits- und Zeitdiagramme benötige, aber ich versuche herauszufinden, welche Art und wie viele verschiedene Ereignisunterstützungsklassen ich benötige und wie die Vererbungsstruktur aussehen wird. Ich möchte mir eine Auswahl an Nachrichtentypen geben, von denen ich weiß, dass sie zusammenarbeiten. Ich nehme an, dann kann ich aus diesen vordefinierten Typen ein EventArgs-Derivat und einen Delegiertyp auswählen, die zur dynamischen Diagramm- und Komponentenerstellungszeit wiederverwendet werden sollen.
Die Hauptsache, die ich nicht herausfinden kann, ist, ob das Ereignis als Attribut oder als Operation modelliert werden soll. Ich habe versucht, eine Zuordnungsklasse für den Delegaten und eine Operation vom Typ OnSomeEvent () mit einem Ereignisstereotyp zu verwenden. Ich mag das nicht, weil eine Veranstaltung keine Operation ist. Ich habe Methoden im Code mit dieser Namenskonvention für On **** () bereits geschützt. Die Signatur des Delegaten, das Multicast-Verhalten und das Beobachtermuster werden durch diesen Ansatz nicht wirklich erfasst.
Welche Methode verwenden andere, um diese komplexen und eng gekoppelten Klassen auszudrücken? In den Diagrammen geht es mir darum, die Schnittstellen im System zu dokumentieren und besser zu verstehen. In diesem Stadium meines Prozesses hoffe ich, die Schnittstellen einzufrieren und mit der Implementierung der Komponenten selbst fortzufahren.