Bessere Unterstützung für getaktete Module

vorhergehende Artikel in: Java dWb+ Komponenten
09.01.2015

Hier stelle ich die nächsten Entwicklungsziele für dWb+ vor. Diesmal wird die Unterstützung von getakteten Modulen verbessert werden.

Aufgabenstellung

Dataflow Workbench dWb+ Eine grundsätzliche Frage blieb bisher bei der Entwicklung von dWb+ noch unbeantwortet: Wie kann man Module schaffen, die nicht bei jedem an den Eingängen eintreffenden Signalen die Verarbeitung starten, sondern erst, wenn ein dediziertes Startsignal eingetroffen ist? Ein immer wieder gern bemühtes Beispiel dafür ist die Simulation digitaler Logik: die Signale liegen an den Eingängen an, werden aber erst dann übernommen, wenn eine bestimmte Flanke am Takteingang detektiert wird. Dazu wurden verschiedene Vorüberlegungen getroffen:

Variante 1

Eine Möglichkeit der Umsetzung wäre denkbar, wenn innerhalb des Workspace zwei verschiedene Arten von Input-Connectoren verfügbar wären: Die bisher bereits verfügbaren werden von eingehenden Daten beliefert - sie agieren als passive Informationsempfänger. Man könnte nun fordern, daß es eine weitere Art geben soll, die die Informationen von den gekoppelten Ausgängen aktiv holt. Das würde zu einem enormen Entwicklungsaufwand führen. Daher wird - das sei hier schon verraten - dieses Projekt zunächst analysiert, jedoch auch sogleich vertagt. Es wäre nämlich dazu notwendig, folgende Aspekte zu ändern/überarbeiten (was praktikabel nur in einem Branch zu bewerkstelligen wäre):

Proxy:
Zur Zeit werden die Verbindungen zwischen Ausgang und Eingang über eine Instanz einer Proxy-Implementation abgewickelt. Eine solche Proxy-Implementation müsste auch für die neuen Eingangsslots geschaffen werden.
Gruppen:
dWb+ erlaubt die hierarchische Organisation von Workspaces. Innerhalb der Gruppen können Input- und Output-Connectoren hinzugefügt werden, die es den Modulen innerhalb der Gruppe erlauben, mit der Umgebung der Gruppe zu kommunizieren. Diese Mechanismen müssten quasi dupliziert werden und ebenfalls die neuen Proxy-Implementationen unterstützen. Das bewirkt die Notwendigkeit, den Code für das Refactoring (Gruppe) umzuschreiben.
UI:
Die aktuell zur Verfügung stehenden Eingänge können problemlos mit mehreren Eingängen verschaltet werden. Es ist zu überdenken, ob diese Möglichkeit auch für Eingänge bestehen soll, die sich ihre Informationen aktiv holen - Momentan scheint es intuitiver zu sein, solche Eingänge auf eine Verbindung zu beschränken. In diesem Fall muss aber wieder eine Entscheidung getroffen werden, ob diese Einschränkung auf die angeschlossenen Verbindungen oder die aktiven wirken soll: Verbindungen können ja in dWb+ deaktiviert werden, so daß man auch die Einschränkung formulieren könnte, daß für die neue Art Eingänge eine beliebige Verbindungsanzahl erlaubt ist, davon jedoch nur maximal 1 aktiv sein darf. Weiterhin muss die Darstellung in der Programmoberfläche auf die neuen Gegebenheiten angepasst werden: die verschiedenen Eingangsarten müssen visuell unterscheidbar sein, beim Drag'n'Drop muss korrekt reagiert werden, wenn eine Verbindung auf einen Eingang neuen Typs fallengelassen werden soll, an dem bereits eine aktive Verbindung angeschlossen ist. Beim Verbinden über Kontextmenü muss korrekt reagiert werden, wenn eine Verbindung auf einen Eingang neuen Typs fallengelassen werden soll, an dem bereits eine aktive Verbindung angeschlossen ist.
Connection unterbrechen
Zur Erhöhung der Übersichtlichkeit ist es möglich, Verbindungen zu unterbrechen: Dabei werden zwei Module in die Verbindung eingeschaltet, die für die Daten, die über die Verbindung übertragen werden, einen Tunnel darstellen. Damit sieht ein Anwender nicht mehr sofort, wo die Daten entlangfließen: Man kann diese Mechanik auch so interpretieren, daß an den Stellen der neuen Module Löcher in den Arbeitstisch gebohrt wurden und die Verbindung zwischen diesen Spezial-Modulen unter dem Arbeitstisch verläuft. Diese Spezialmodule müssten ebenfalls auf die neuen Gegebenheiten angepasst werden.
Module mit variabler Anzahl von Eingängen
Die Möglichkeit, Module mit einer variablen Anzahl von Eingängen zu erstellen und zu benutzen, muß auf die neuen Gegebenheiten angepasst werden.
Die Möglichkeiten, diese neue Art von Eingängen umzusetzen würde aber auch erfordern, daß dWb+ beim Hinzufügen eines neuen Moduls Informationen erlangen kann, aus denen ersichtlich ist, welche Eingänge zu welcher Sorte gehören. Es könnten mehrere Varianten zur Umsetzung ersonnen werden: Eine davon wäre, daß alle Properties, die das Attribut hidden gesetzt haben und schreibbar sind. Diese Variante scheint intuitiv - ohne lange darüber nachzudenken - nicht optimal. Interessant erscheint der Ansatz, diese Unterscheidung nicht vorzunehmen, sondern den UseCase - Verarbeitung wird über ein gesondertes Signal angestoßen - etwas anders zu interpretieren. Die Tatsache, daß Eingänge in spezieller Art und Weise (explizit oder implizit) gekennzeichnet werden müssten läuft ja eigentlich der Philosophie von dWb+ entgegen - beliebige Java-Klassen als Module nutzen zu können und so wenige Anforderungen an diese zu stellen als möglich. Daher wurde folgende Idee entwickelt:

Variante 2 - Latch

Es wird Unterstützung für Entwickler bereitgestellt, die es unkompliziert erlaubt, eingehende Daten zwischenzuspeichern. Das Modul kann einfach auf diesen Zwischenspeicher zugreifen. Wenn ein Signal am Eingang eintrifft, kann dessen Wert zwischengespeichert werden. Wenn die Daten verarbeitet werden sollen, ist problemloser typsicherer Zugriff auf diese Daten möglich. Für die Umsetzung dieses Modells wären folgende Arbeiten zu erledigen:
Einrichtung der Infrastruktur
Die Infrastruktur zum Speichern der Daten für jeden Eingang und den typsicheren Zugriff auf den Speicher muss geschaffen werden
Entwicklerdokumentation
Die Dokumentation muss entsprechend erweitert werden
Entscheidung über Taktsignale
Wie die Auslösung der Verarbeitung geschehen soll, muss festgelegt werden. Dazu lassen sich mehrere Alternative diskutieren - eine davon wäre, dafür einen dedizierten Eingang festzulegen, eine weitere wäre, den Takt über einen BeanContextService bereitzustellen.
Entscheidung über Verhalten bei fehlendem Takt
Wie geht man mit fehlendem Takt um - geht da Modul dann wieder in den Modus über, indem es die Verarbeitung startet, sobald irgendeiner der Eingänge neue Daten sieht?
Verarbeitung bei Takt, aber fehlendem Eingang
Es wird aktuell überlegt, das Verhalten von dWb+ in folgender Beziehung zu ändern oder zumindest konfigurierbar zu machen: Kommt das Taktsignal eher, als das vorgeschaltete Modul Eingangsdaten liefert - wie soll sich das Modul verhalten?
  • Keine Verarbeitung
  • Verbindung liefert immer Daten, sobald sie aktiviert wird. Das würde dafür sorgen, daß immer Daten zur Verfügung stehen und das Problem gar nicht auftaucht. Dafür müssten aber noch genauere Analysen durchgeführt werden, um alle Implikationen einer so tiefgreifenden Änderung abschätzen und bewerten zu können.
Variante 2 wird demnächst umgesetzt.

Artikel, die hierher verlinken

Methoden mit mehreren Parametern als Eingang in dWb+

03.04.2016

Bereits in einem früheren Beitrag wurde die Unterstützung von getakteten Modulen diskutiert. In diesem Zusammenhang habe ich über die Möglichkeit der Nutzung von Methoden mit mehr als einem Parameter als Eingänge für Module nachgedacht...

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • Fährnisse des Buildprozesses unter Windows

    17.07.2019

    Nachdem ich begonnen hatte, mich mit der Beschleunigung der Berechnung des Mandelbrot-Fraktals unter Zuhilfenahme der Shadereinheiten in Graphikkarten zu beschäftigen und erste Erfolge feiern konnte, wollte ich das mal auf einer richtigen Graphikkarte ausprobieren...

    Weiterlesen...

Neueste Artikel

  • Datenvalidierung UTF8 mit BiDi-Steuerzeichen (TrojanSource 2.0)

    Ich bin heute nochmal inspiriert worden, weiter über die Trojan Source Vulnerability nachzudenken. Meiner Meinung nach bestehen hier noch Probleme - speziell bei Nutzereingaben oder Daten, die über externe Schnittstellen ampfangen werden.

    Weiterlesen...
  • OpenStreetMap Navi als Docker-Container

    Ich habe die auf OpenStreetMap basierende OpenSource Navigationslösung Graphhopper in einen Docker-Container gepackt und als neuestes Mitglied in meinem Docker-Zoo willkommen geheißen.

    Weiterlesen...
  • SQL-Aggregatfunktionen in SQLite als BeanShell-Scripts

    Ich habe neulich über eine Möglichkeit berichtet, SQLite mittels der sQLshell und Beanshell-Skripten um SQL-Funktionen zu erweitern. In diesem Artikel versprach ich auch, über eine solche Möglichkeit für Aggregatfunktionen zu berichten.

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.