Generiert – Architekturcompiler für Event-Based Components

Da hab ich ja was angerichtet: Event-based Components ziehen immer größere Kreise. Immer mehr Entwickler “wollen es tun”. Selten habe ich soviel direktes positives Feedback zu einem Konzept bekommen. Irgendwie scheine ich da einen Nerv getroffen zu haben.

Bei allem Wohlwollen haben EBCs aber natürlich auch noch Schwachstellen. Die kommen durch das Feedback und das “Herumspielen” mit dem Konzept ans Licht. Eines ist die Verdrahtung. Die ist zwar technisch simpel, aber nervig zu implementieren. Weil nicht nur wenige Komponenteninstanzen in andere zu injizieren sind, sondern viele Pins der Komponenteninstanzen mit denen anderer verbunden werden müssen, steigt der Aufwand für die Laufzeitintegration. Dem stehen zwar große Gewinne gegenüber – doch nervig bleibt die Verdrahtung.

Besser würde die Lage natürlich, gäbe es einen hübschen EBC Designer à la LabVIEW.

Soweit sind wir aber noch nicht. Das braucht noch etwas mehr Erfahrung mit EBCs, glaube ich. Und auch Zeit, denn einen Designer zu basteln, ist kein Pappenstil.

Geht´s denn nicht aber auch ohne Designer schon ein bisschen einfacher? Einen “automatischen Verdrahter” hatte ich ja schonmal gebastelt. Der funktioniert aber nur in sehr einfachen Szenarien ausreichend. Wenn es komplizierter wird, reicht “Verdrahtung nach Konvention” nicht mehr aus. Dann müssten zusätzliche Informationen her. Dann wären wir wieder bei einer Architekturbeschreibung.

Also habe ich mir gedacht: Warum nicht mit einer Architekturbeschreibung ohne Designer anfangen? Also habe ich mal “rumgesponnen”. Erst habe ich mir ne textuelle DSL überlegt. Doch dann dachte ich, dass es noch besser wäre, noch klarer zu entkoppeln. Also bin ich auf das gute alte XML gekommen.

Wie wir am Ende Architekturen entwerfen und formulieren, ist egal. Eine graphische oder auch textuelle Notation wird sich immer in ein XML-Format übersetzen lassen. Das kann die Konstante in der Mitte sein zwischen Entwickler und Code.

Deshalb habe ich mir mal ein ganz einfaches Format überlegt, mit dem man einfache EBC-Architekturen beschreiben kann. Als Beispiel eine Stopuhr-Anwendung. Zuerst die Architektur gemalt in Visio:

Und hier die Übersetzung in das XML-Format. Ich nenne es mal ebclang für EBC Language:

Die Komponenten sind für sich mit ihren Output- und Input-Pins beschrieben, anschließend die Verdrahtung. Ich denke, das ist recht einfach zu verstehen. Geschachtelte Komponenten habe ich einstweilen allerdings noch außen vor gelassen.

Nachdem ich so eine XML-Architekturbeschreibung hatte, habe ich die von Hand ganz systematisch in Codeartefakte übersetzt. Das funktionierte sehr einfach. Es lässt sich gut automatisieren.

Deshalb habe ich in einem Anfall von Lust am “mud wrestling” ;-) einen Übersetzer dafür gebastelt. Der ist aus dem Stand gleich zu sehr hübschem Brownfield Code geworden. Aber das macht nichts. Er ist als Spike Solution gedacht, nicht mehr. Ich wollte mit dem Code nur das Feld der Artefaktgenerierung explorieren, bevor ich eine “richtige” Version entwickle.

Der ebclang.compiler übersetzt eine XML-Architekturdefinition wie oben in Assemblies und Visual Studio Projekte. Das sind im Einzelnen:

• myapp.messages.dll und myapp.messages.csproj: Ein Projekt, das alle Nachrichtentypen implementiert. Der Compiler legt jeden Nachrichtentyp, der kein Standardtyp ist, darin als Klasse an.
• myapp.specifications.dll: Eine Assembly, die die Komponenten in Form von Interfaces spezifiziert.
• myapp.wiring.dll: Eine Assembly, die Komponenteninstanzen verdrahtet.

“myapp” steht für den Applikationsnamen wie im XML auf <MainBoard> angegeben. Die Spezifikation und das Wiring werden bewusst nur als Assemblies erzeugt, damit niemand auf die Idee kommt, sie zu verändern. Darin steckt die manifestierte Architektur. Die soll nur durch das XML veränderbar sein.

Die Nachrichtentypen jedoch müssen “nachgebessert” werden können. Deshalb darf man am messages-Projekt arbeiten. Der Compiler überschreibt Nachrichtentypquelldateien nicht.

Zusätzlich legt der Compiler noch Werkbänke für die Komponenten an. Das sind VS Projektmappen mit zwei Projekten, einem für die Komponentenimplementation und einem für deren Tests.

Das Vorgehen beim Entwurf einer EBC-Architektur ist mit dem Compiler wie folgt:

1. Anlegen eines Verzeichnisbaums für die Artefakte. Hier die Minimalstruktur:

Wurzelverzeichnis, darunter ein Verzeichnis lib/ mit nunit.framework.dll und weiteren für die Anwendung nötigen Bibliotheken. Und das Verzeichnis arc/, in dem die Architekturbeschreibung liegt. (Das Batch-File ruft den ebclang-Compiler für die XML-Datei auf.)

Nach Übersetzung der Architekturdefinition sieht der Artefaktbaum so aus:

Die .log-Dateien enthalten den C#-Compiler Output der Übersetzungen der myapp.* Projekte. Falls mal was schief gegangen sein sollte, darin nachschauen, bei welchem Generierungsschritt es gehakt hat. Der Compiler ist eine Konsolenanwendung und liefert auch noch Informationen während der Übersetzung.

Die Projekte *.specifications und *.wiring sollten nicht weiter beachtet werden. Der Compiler könnte sie genauso gut löschen. Ich habe sie bisher zur Fehlersuche aber noch drin gelassen. *.messagetypes enthält das Projekt, in dem die Nachrichtentypen “ausgefleischt” werden können.

Wichtig ist das bin-Verzeichnis in arc/:

Hier sind die Assemblies angekommen, die der Compiler erzeugt hat. Von hier müssen sie in allen weiteren Anwendungsprojekten referenziert werden. ebclang.basics.dll enthält bisher nur einen Nachrichtentypen für bidirektionale Kommunikation (Request<,>) und seine Erweiterungsmethoden.

Mehr ist eigentlich nicht nötig als Vorarbeit durch den Compiler. Auf der Basis der Assemblies kann man loslegen mit der Anwendungsimplementation. Die aufwändige Verdrahtung steckt ja in *.wiring.dll. Das EBC-Leben ist damit einfacher geworden.

Dennoch tut der Compiler etwas mehr. Er erzeugt auch noch Gerüstprojektmappen für die Komponenten im source/ Verzeichnis des Artefaktbaumes:

Diese Werkbänke geben den Rahmen vor, in dem Komponenten implementiert werden sollen. Erstens fokussieren sie den Blick, indem sie jede Komponente in eine eigene Projektmappe stellen. Zweitens geben sie vor, dass automatisiert getestet werden muss. Drittens setzen sie schon die Referenzen auf die generierten Assemblies und stellen den Output-Path auf ein globales bin-Verzeichnis.

Das mögen Kleinigkeiten sein. Doch in Clean Code Developer Seminaren, die viel mit Architektur zu tun haben, bemerken wir immer wieder, dass diese Kleinigkeiten viel Zeit kosten. Also habe ich versucht, hier eine erste Linderung zu bringen. Die ist noch nicht perfekt, weil z.B. keine Klasse für die Komponentenimplementation generiert wird, aber sie ist ein Anfang.

Was bleibt ist die Visualisierung von Architekturdefinitionen. Die soll ultimativ natürlich ein Designer übernehmen. Bis dahin wollte ich aber nicht warten. Also habe ich noch einen kleinen Visualisierer für die XML-Definitionen gebastelt. Den macht man einfach parallel zu Visual Studio oder einem anderen XML-Editor auf und lädt die Architekturdatei. Immer, wenn die sich verändert, aktualisiert man die Diagrammdarstellung und bekommt visuelles Feedback.

Die Visualisierung ist natürlich nicht interaktiv und auch nicht besonders hübsch. Aber sie erfüllt erstmal ihren Zweck, denke ich. Und der ist, dass – wer will – einen leichteren Einstieg in den Umgang mit Event-based Components bekommt.

Am Flipchart mit einer Architekturskizze beginnen, die in das XML-Format übersetzen und dabei die Übersetzung mit dem Visualisierer immer wieder überprüfen. Am Ende die Artefakte mit dem Compiler erzeugen und Nachrichtentypen sowie die Komponentenimplementationen in Visual Studio entwickeln.

Fehlt am Ende nur noch eines: Ein Programm, dass die ganzen Komponenten instanziert und die generierte Verdrahtung aufruft. So ein Programm – ich nenne es Host – generiert der Compiler noch nicht. Aber es ist schnell geschrieben. Dem Compiler-Download liegt es in der Nachher-Version der Beispielanwendung bei:

Mit einem DI Container wie Unity sieht ein Host z.B. so aus:

   19 static void Main()

   20 {

   21     Application.EnableVisualStyles();

   22     Application.SetCompatibleTextRenderingDefault(false);

   23 

   24     // Prepare Build

   25     IUnityContainer uc = new UnityContainer();

   26     uc.RegisterType<IPortal, FrmPortal>(new ContainerControlledLifetimeManager());

   27     uc.RegisterType<IStopuhr, Stopuhr>();

   28     uc.RegisterType<MainBoard, MainBoard>();

   29 

   30     // Build & Bind

   31     var mainboard = uc.Resolve<MainBoard>();

   32 

   33     // Run

   34     Application.Run((Form)uc.Resolve<IPortal>());

   35 }

Das Portal ist ein Singleton, damit es nicht zweimal instanziert wird. Einmal während der Injektion in das MainBoard und einmal am Schluss bei Run().

Wer diesen ersten Wurf für einen Architekturcompiler für EBCs interessant findet, der kann ihn hier herunterladen. Wie immer freue ich mich über Feedback.