| 

.NET C# Java Javascript Exception

2
Im letzten Beitrag habe ich über Visualisierung im Quellcode geschrieben. Natürlich ist das nicht das Ende von allen. Es geht immer besser. Aktuell gibt es aber noch kein Tool was mir wirklich für die Visualisierung von Flows geeignet erscheint. Idealerweise erfolgt nicht nur eine Visualisierung bestehender Komponenten sondern auch das Design. Im Ansatz und umständlich […]

Im letzten Beitrag habe ich über Visualisierung im Quellcode geschrieben. Natürlich ist das nicht das Ende von allen. Es geht immer besser. Aktuell gibt es aber noch kein Tool was mir wirklich für die Visualisierung von Flows geeignet erscheint. Idealerweise erfolgt nicht nur eine Visualisierung bestehender Komponenten sondern auch das Design. Im Ansatz und umständlich macht das der Sybase Powerdesigner z.B. mit seinem Komponenten Diagramm.

Welche Diagramm Typen sind den für eine Visualisierung geeignet? UML bietet da bereits einige Möglichkeiten. Mir sagen besonders das  “Activity Diagramm” und das “BPMN Diagramm” zu. Das “Component Diagramm” ist naheliegend, übertrifft meiner Meinung jedoch nicht das “Activity Diagramm” für diesen Einsatzzweck. Die effizienteste Möglichkeit wäre die Umsetzung als Visual Studio Extension. Natürlich müssten der sich Quellcode und Visualisierung bei Änderungen gegenseitig aktualisieren.

Frei nach dieser Flow Design Notation sollte das Tool die Verbindungen zwischen den Klassen visualisieren und das Design ermöglich. Ein Beispiel. Wir ziehen eine Verbindung von einer Klasse zu einer anderen. Die Verbindung selbst benötigt nur einen Datentyp, Quelle und Ziel. Die Quelle ist ein Event der Klasse an welcher die Verbindung begonnen wurde. Das Ziele ist eine Funktion der Klasse zu welcher die Verbindung gezogen wurde. Ähnlich wie die Dialoge für die Fremdschlüssel bei Datenbanken müssten hier diese Angaben erfolgen. Für Quelle und Ziel könnte ein neuer Name angegeben oder ein Name mit passenden Datentyp ausgewählt werden. So würde alles zusammen passen. Eine Änderungen des Datentyps einer Verbindung hätte die Änderung aller abhängigen Events, Funktionen und weiteren Verbindungen zur Folge.

image

Das dies nur ein Ansatz ist um das gesamte Umfeld zu beschreiben ist mir klar. Als nächstes müssten die beliebige Schachtelung der Komponenten berücksichtigt werden. Der erwähnte Powerdesigner kann das nach einigen Zutun mit dem “Component Diagram” so darstellen.

image

Das wäre ein Beispiel für eine Schachtelung. Allerdings können Komponenten beliebig unter verschiedenen Aspekten verknüpft werden. Ein Diagramm wird nicht ausreichen, jedoch könnte jedes Diagramm im Codebehind die entsprechenden Verknüpfungen für den Aspekt vornehmen. Damit wäre wiederum eine Schachtelung nicht notwendig, sogar störend.

Die Beschränkung auf einzelne Aspekte stört mich nicht, ich finde sie hilfreich. Beispielsweise soll durch die Auswahl einer Kategorie eine Liste von Dokumenten geladen werden. Die beteiligten sind hier zwei ViewModels, ein Service und optional die Komponten zur asynchronen Ausführung.

image

Das einzige was die diese Komponente (LoadDocumentsAfterCategoryChanged) tun muss, ist die Verdrahtung vorzunehmen. Die beteiligten Komponenten müssen nichts voneinander wissen, jedoch dieser Komponente bekannt sein. Und hierbei fällt auf das Async und Sync nur innerhalb der Komponente einen Sinn machen. Im Diagramm müssten damit interne Komponenten und Abhängigkeiten unterschieden und entsprechend markiert werden.  Markierung durch Attribute oder IDependency<T>, ich weiß es noch nicht.

Als nächstes fällt mir ein, das der DocumentService kritisch bezüglich des Events DocumentsLoaded ist. Es kann mehrere Abonnenten besitzen. Jedoch soll in diesem Fall nur das DocumentListViewModel informiert werden.

Async.Processing += DocumentService.LoadDocumentByCategory;
DocumentService.DocumentLoaded += Sync.Process;

// wird zu

Async.Processing += c => DocumentService.LoadDocumentByCategory(c, Sync.Process)

Wie könnte das denn dargestellt werden? Spontan habe ich hier keine gute Idee, vielleicht so?

image

An dieser Stelle unterbreche ich den Ideenfluss, was haben wir bis jetzt:

  • Ein paar Ideen wie Visualisierung aussehen könnte
  • Eine Vorstellung wie die Visualisierung in ein Projekt integriert werden kann
  • Einige Regeln und viele neue Fragen

Und das Fazit:

Ich finde diese Visualisierung nützlich und effektiv, wenn sie mal ausgereift ist. Ein separates Tooling außerhalb der Entwicklungsumgebung ist mir zu wenig.


event-based-components flow uml visualisierung
Schreibe einen Kommentar:
Themen:
visualisierung uml flow event-based-components
Entweder einloggen... ...oder ohne Wartezeit registrieren
Benutzername
Passwort
Passwort wiederholen
E-Mail