Das Material – Begriffe und Definitionen der EBC

Ich hatte vor die Begriffe und Definitionen der EBC im Wiki vom Ralf Westphal bei codeplex zu hinterlassen. Das werde ich auch noch tun, wenn ich mit diesem Blog hier fertig bin und ist dann nachzulesen unter codeplex – ebclang. Bis ich aber die Beschreibung auf englisch formulieren kann, brauche ich erst die deutsche Variante, die hier nachzulesen ist.

Anstoß

Im Forum (Google Groups - EBC) haben wir über die Begriffe und Definitionen diskutiert, die zu den EBCs gehören. Wir sind auch der Frage auf den Grund gegangen, wie EBC umgesetzt werden soll oder haben die Verwendung von EBC geklärt (hoffe ich doch). Daher sehe ich mich nun in der Lage eine Zusammenfassung zu diesen Themen zu schreiben.
Viele Vorschläge standen zur Debatte, vor allem die Hinweise, dass es doch schon Lösungen und Begriffe für ähnliche oder gar gleiche Ansätze gibt. Doch im Laufe der Postings stellte sich heraus, dass die bisherigen Begriffe noch zu abstrakt sind oder der Sinn hinter dem Ganzen nicht erschlossen werden kann. Daher kommt hier der Versuch iterativ das EBC Paradigma einzuführen und umzusetzen, in dem die wichtigsten und einfachsten Begriffe und Definitionen aufgeschrieben werden.
Ich möchte auch vorab erwähnen, das Verbesserungsvorschläge immer wieder willkommen sind.

Definitionen der EBC

Zunächst einmal muss festgelegt werden, was erreicht werden soll. Was soll mit dem EBC Paradigma verbessert werden, was wird einfacher und wo kann es angewendet werden?

Das Ziel von EBC

Event Based Components stellen den nächsten Schritt der Softwareentwicklung dar. Die Kopplung von Komponenten erfolgt nicht mehr über Injection, sondern über Verknüpfungen und Nachrichten. Auf diese Weise werden die Komponenten weiter entkoppelt und somit flexibler. Das Ziel ist es also, flexibel einsetzbare unabhängige Komponenten zu schaffen.

Der Einsatzbereich

Es gibt keine Festlegung über den Einsatzbereich, so wie es bisher von den Event gesteuerten Komponenten erwartet wird. Diese wurden bisher für den UI Bereich vorbehalten, was aber keinen Sinn macht, wenn es sich nur darauf beschränkt.
EBCs können demnach in allen Bereichen einer Systemlösung verwendet werden.

Wichtige Aussagen

1. Auf einer Platine (Board) werden nur Komponenten und Bauteile (Components, Parts) verdrahtet (wired)
2. Events sind ein probates Mittel Nachrichten (Messages) zu versenden
3. Es gibt keinen Basistypen für Nachrichten
4. EBCs lassen sich in Komponentendiagrammen  bzw. Schaltplänen (Wiring Diagram) grafisch darstellen
5. Eine Komponente kann 0-n Ein- und/oder Ausgänge haben

Die Begriffe der EBC

Die Bestandteile einer EBC sind denkbar einfach. Als Grundlage für die Begriffsfindung wird die Elektrotechnik herangezogen, weil es in diesem Bereich viele fertige Begriffe gibt, die man leicht verstehen kann.
Das EBC Paradigma stellt folgende Begriffe bereit:

• Component,
• Part,
• Board
• Pin,
• Message,
• Wiring und
• Wiring Diagram

Component

Alles was logische Elemente enthält ist eine Component. Sie ist der Oberbegriff für einzelne oder zusammengesetzte Elemente. Jede Component wird durch ihr Schaltbild, in Form eines Contracts/Interfaces, beschrieben.

EBC Component Contract

1. interface IFoo {
2.     void In_ReciveMessage(InMessage message);
3.     event OutPin<OutMessage> Out_XYZ;
4. }

Eine Component kann 0-n Ein- und Ausgänge (Pins, siehe weiter unten) besitzen.

Part

Ein Part ist die kleine logische Einheit der Components. Er stellt ein einzelnes Bauteil dar und erledigt im System genau eine Aufgabe bzw. einen Concern.

Board

Ein Board stellt die Verbindungen zwischen Parts her und ist mit einer Leiterplatte vergleichbar. Auf einem Board werden nur Parts verknüpft und keinerlei funktionale Anforderungen umgesetzt.

Baugruppe oder Composite Component

Diese Spezialform der Component bedarf noch einer intensiven Prüfung, ob es als Begriff aufgenommen wird. Ein Composite stellt eine Gruppe von Parts dar, sprich also eine klassische Komponente mit Pins (siehe weiter unten). Da aber die Parts wiederum im Composite verknüpft werden würden, hätten wir den Fall, dass ein Composite die Aufgabe von einem Board erledigt, aber auch funktionale Elemente enthält.

Pin

Ein Pin ist die Verbindungsstelle zwischen den Components. Diese Verbindungen werden im Board eingerichtet. Sie bilden also die Basis der Kommunikation. Pins unterscheiden sich in ihrer Kommunikationsrichtung. Es gibt In und Out Pins, die wiederum frei definiert werden können.

In

In Pin

1. void In_ReciveMessage(InMessage message);

Ein In Pin wird immer als void definiert und mit “In” im Namen eingeleitet. Ein In Pin muss nicht zwangsweise eine Message erhalten, aber wenn doch, dann sollte es auch nur genau eine Message sein.

Out

Out Pin

1. event OutPin<OutMessage> Out_XYZ;

Ein Out Pin wird immer als event bzw. Multicast Delegaten definiert und mit “Out” im Namen eingeleitet. Auch hier gilt wieder, dass der Pin keine Message versenden muss, wenn dann doch, dann sollte es genau eine Message sein.

Trigger

Ich könnte mir vorstellen, die Pins ohne Message auch als Trigger zu bezeichnen. Sie stoßen einen Prozess nur an, benötigen dazu aber keine Nachricht.

Message

Bei einer Message handelt sich um die Botschaft, den Daten, die an eine Component gesendet wird. Die Message hat keine bestimmte Definition oder ist von einem bestimmten Typ. Dazu ist es noch nicht an der Zeit Basistypen zu definieren.

Wiring

Dieser Begriff beschreibt das Vorgehen, wenn die Pins auf dem Board miteinander verbunden, verdrahtet werden. Er ist ein fassbarer und leicht verständlicher Begriff und passt ausgezeichnet zu den Schaltplänen, den wiring diagrams.

Wiring Diagram

Zum dokumentieren von EBCs werden sogenannte wiring diagrams angelegt. Sie zeige auf unterschiedlichen Abstraktionsebenen die Verdrahtungen der Components an. Wiring Diagrams können als Grundlage für Generatoren dienen, um aus formulierten EBCs Code zu erzeugen.

EBC Syntax (C#)

Der Code zum Wire Diagramm sieht dann folgendermaßen aus:
Definition der Components, also die Beschreibung der Pins je Komponente.

EBC Contracts

1. interface IBoard {
2.     void In_ProcessMessage(int message);
3.     event OutPin<DateTime> Out_BoardMessage;
4. }
5.  
6. interface IFoo {
7.     void In_ReciveMessage(int message);
8.     event OutPin<string> Out_XYZ;
9. }
10.  
11. interface IBar {
12.     void In_ReciveOtherMessage(string message);
13.     event OutPin<DateTime> Out_ABC;
14. }

Implementierung der Component Contracts

EBC Components

1. class Foo : IFoo {
2.     public event OutPin<string> Out_XYZ = delegate { };
3.  
4.     public void In_ReciveMessage(int message) {
5.         throw new NotImplementedException();
6.     }
7. }
8.  
9. class Bar : IBar{
10.     public event OutPin<DateTime> Out_ABC = delegate { };
11.  
12.     public void In_ReciveOtherMessage(string message) {
13.         throw new NotImplementedException();
14.     }
15. }

Und die Verdrahtung entsprechend dem Wire Diagram

EBC Board

1. class Board : IBoard {
2.  
3.     public event OutPin<DateTime> Out_BoardMessage = delegate { };
4.     private Action<int> _startSequence;
5.  
6.     public Board(IFoo foo, IBar bar) {
7.         this._startSequence = foo.In_ReciveMessage;
8.         foo.Out_XYZ += bar.In_ReciveOtherMessage;
9.         bar.Out_ABC += this.Out_BoardMessage;
10.     }
11.  
12.     public void In_ReciveBoardMessage(int message) {
13.         this._startSequence(message);
14.     }
15. }

Fazit

Das ist der Anfang, sicher werden noch weitere Begriffe und Definitionen hinzukommen, aber es sollte ein Grundstein gelegt werden.

Jan