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

Aufgabenstellung

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