Letzte Woche war ich beim CCD-Praktikum von Ralf Westphal und Stefan Lieser. Da gab es viel Neues zu entdecken und ich bin erstmals praktisch mit EBCs - die ich bis dahin immer nur aus Artikeln und Blog-Beiträgen kannte - in Berührung gekommen. Ich habe mir zu dieser in .NET recht neuen Technologie Gedanken gemacht und möchte im folgenden Vor- und Nachteile, wie ich sie sehe, vorstellen.
Fehlende Tools
Der größte Nachteil ist sicherlich, dass man im Moment noch alles per Hand entwickeln muss. Schön wäre ein Generator, der aus einem EBC-Diagramm Projekte, Klassen und Bauteile-Verdrahtung erzeugt. Das ist momentan noch sehr aufwändig. Ralf hat bei einer Aufgabe während des Praktikums ca. 1 Stunde benötigt um all das manuell anzulegen. Außerdem haben wir bei einer Platine einen Bug in der Verdrahtung eingebaut, was mit einem Tool nicht passiert wäre.
Keine Standard-Bibliothek
Eine Library mit Standard-Bauteilen ist noch im Entstehen. Es ist zwar nicht schwierig, selbst Joiner, Splitter usw. zu entwickeln, aber Wiederverwendung wäre natürlich trotzdem von Vorteil. Ich bin auch nicht ganz zufrieden damit, dass Output-Pins als Events definiert sind. Aus meiner Sicht wären hier eine Pin-Klasse die bessere Wahl. Features wie automatisches Logging des Programmflusses oder Debugging-Hilfen (Assertion, wenn ein Output-Pin aufgerufen wird, aber nicht verdrahtet ist) wären damit machbar.
Keine Standards
Dass EBCs noch recht neu sind zeigte sich im Praktikum auch bei einer Diskussion um die Begrifflichkeiten: eine Platine wird in Baugruppe umbenannt, “EBC” könnte durch einen anderen, passenderen Begriff ersetzt werden. An diese Umbenennungen kann man sich gewöhnen. Wichtiger aus meiner Sicht sind aber fehlende Notationsregeln für die EBC-Diagramme, die über Drähte, Platinen und Bauteile hinausgehen. Damit meine ich spezielle Symbole für Standardbauteile. Wir haben beispielsweise “normale” Joiner kennengelernt und Joiner, die ihren Ausgang nur triggern, wenn am zweiten Input-Pin ein Signal ankommt. Es wird dann immer nur der zuletzt angekommene Wert am ersten Input-Pin weitergeleitet. Wir mussten ein Symbol erfinden – legt man dieses Diagramm einem Unbeteiligten vor, hat er keine Ahnung was für ein Bauteil damit gemeint ist.
Direkte Übersetzung von Diagramm in Code
Mit EBCs kann man Diagramme direkt in Code übersetzen. Es gibt zwischen Design und Implementierung praktisch keine Lücken. Die Architektur spiegelt sich daher auf allen Ebenen wieder und mit entsprechenden Tools wäre eine Synchronisation zwischen Code und Diagramm möglich.
Gedankliche Fokussierung / Detailtiefe
Während der Planungsphase kann man auf beliebiger Detailtiefe in das Problem eintauchen. Wenn man sich über die inneren Vorgänge eines Bauteils noch unsicher ist oder dies für den Moment ausklammern möchte, ist das kein Problem. Man kann später in ein Bauteil hineinzoomen. Vielleicht ist es so komplex, dass man eine eigene Platine daraus baut? Vielleicht ist es aber auch ein triviales Problem. Man muss sich während der Planung hierüber keine Gedanken machen sondern kann sich auf beliebiger Abstraktionsebene bewegen.
Testen
Man kann für EBC-Bauteile sehr einfach Unit Tests schreiben. Da sie in der Regel keine Abhängigkeiten nach außen haben, ist man nicht auf Mocks angewiesen.
Lösung von Komplexität
Den größten Vorteil von EBCs sehe ich darin, dass man mit ihnen jegliche Komplexität sauber lösen kann. Ein EBC-Bauteil kommuniziert mit seiner Umwelt nur über seine Pins, Abhängigkeiten gibt es deshalb nicht. Die Koordination, der Schaltplan findet an einem Ort statt - der Platine. Es ist deshalb ein leichtes, ein Softwaresystem beliebig zu erweitern oder zu ändern. Man kann beispielsweise Vorgänge ohne großen Aufwand asynchron machen, indem man auf dem Draht ein Standard-Bauteil “Asynchronisierer” zwischenschaltet. Für die UI braucht man dann ein Bauteil um gegen den UI-Thread zu synchronisieren. Oder falls z.B. eine neue Ansicht Werte eines Berechnungs-Bauteils anzeigen soll, hängt man die Ansicht einfach an den Output-Pin der Berechnungslogik. Geändert werden muss dafür immer nur die Platine.
Fazit und Ausblick
EBCs sind ein vielversprechender Ansatz, der hoffentlich in Zukunft noch mehr Beachtung finden wird. Die Produktivität kann noch durch geeignete Tools und Bibliotheken verbessert werden. Nachrichtenbasierte Kommunikation ist übrigens nichts Neues: Klaus Aschenbrenner hat in der dotnetpro 05.2010 die experimentelle Programmiersprache Axum vorgestellt, bei der nachrichtenbasierte Kommunikation idiomatisch ist. Es bleibt abzuwarten, ob Microsoft Axum in die .NET-Familie aufnehmen wird und inwieweit Konzepte in die anderen .NET-Sprachen übernommen werden.
